Il 11/04/2013 18:28, Peter Maydell ha scritto:
> On 11 April 2013 17:10, Paolo Bonzini <pbonzini@redhat.com> wrote:>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>> This doesn't look right. The MemoryRegion system isn't> hw-specific, it's a part of the basic QEMU emulation> system which provides functionality to hw/ and other> things (like cputlb.c).
The accelerator- and target-independent parts of the basic emulation are
already in hw/core (not much really, but consider that CPUs are device
and depend on hw/core/qdev.c). The memory API is simply the interface
between the accelerators and hw/ (boards & device models).
In fact, apart from large parts of exec.c which are really part of the
memory API implementation (but I'm not moving it in this patch for
simplicity), the other users of the memory API are really the
accelerators. KVM and Xen only use listeners, TCG needs more low-level
access in cputlb.c and translate-all.c but that's pretty much it.
Paolo

On 11 April 2013 18:09, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 11/04/2013 18:28, Peter Maydell ha scritto:>> On 11 April 2013 17:10, Paolo Bonzini <pbonzini@redhat.com> wrote:>>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>>> This doesn't look right. The MemoryRegion system isn't>> hw-specific, it's a part of the basic QEMU emulation>> system which provides functionality to hw/ and other>> things (like cputlb.c).>> The accelerator- and target-independent parts of the basic emulation are> already in hw/core (not much really, but consider that CPUs are device> and depend on hw/core/qdev.c). The memory API is simply the interface> between the accelerators and hw/ (boards & device models).
Yes, so it should be provided in the place we put our accelerator
implementation (ie .): it is functionality and interface exposed
*to* the code in hw/, not functionality and interface provided
*by* hw/.
-- PMM

Il 11/04/2013 19:14, Peter Maydell ha scritto:
> On 11 April 2013 18:09, Paolo Bonzini <pbonzini@redhat.com> wrote:>> Il 11/04/2013 18:28, Peter Maydell ha scritto:>>> On 11 April 2013 17:10, Paolo Bonzini <pbonzini@redhat.com> wrote:>>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>>>> This doesn't look right. The MemoryRegion system isn't>>> hw-specific, it's a part of the basic QEMU emulation>>> system which provides functionality to hw/ and other>>> things (like cputlb.c).>>>> The accelerator- and target-independent parts of the basic emulation are>> already in hw/core (not much really, but consider that CPUs are device>> and depend on hw/core/qdev.c). The memory API is simply the interface>> between the accelerators and hw/ (boards & device models).> > Yes, so it should be provided in the place we put our accelerator> implementation (ie .): it is functionality and interface exposed> *to* the code in hw/, not functionality and interface provided> *by* hw/.
Ok, the historical practice was that qdev core was in hw/, and that's
what I tried to follow. It makes sense either way to me.
But then patch 11 also has to be dropped, otherwise it doesn't make
sense. Michael, what do you think?
Paolo

On Thu, Apr 11, 2013 at 08:18:52PM +0200, Paolo Bonzini wrote:
> Il 11/04/2013 19:14, Peter Maydell ha scritto:> > On 11 April 2013 18:09, Paolo Bonzini <pbonzini@redhat.com> wrote:> >> Il 11/04/2013 18:28, Peter Maydell ha scritto:> >>> On 11 April 2013 17:10, Paolo Bonzini <pbonzini@redhat.com> wrote:> >>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>> >>> This doesn't look right. The MemoryRegion system isn't> >>> hw-specific, it's a part of the basic QEMU emulation> >>> system which provides functionality to hw/ and other> >>> things (like cputlb.c).> >>> >> The accelerator- and target-independent parts of the basic emulation are> >> already in hw/core (not much really, but consider that CPUs are device> >> and depend on hw/core/qdev.c). The memory API is simply the interface> >> between the accelerators and hw/ (boards & device models).> > > > Yes, so it should be provided in the place we put our accelerator> > implementation (ie .): it is functionality and interface exposed> > *to* the code in hw/, not functionality and interface provided> > *by* hw/.> > Ok, the historical practice was that qdev core was in hw/, and that's> what I tried to follow. It makes sense either way to me.> > But then patch 11 also has to be dropped, otherwise it doesn't make> sense. Michael, what do you think?> > Paolo
I agree.