Re: [Qemu-devel] [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address()

[Scott Wood <scottwood@freescale.com>]

On 03/23/2013 06:24:49 AM, Peter Maydell wrote:
> On 22 March 2013 22:05, Scott Wood <scottwood@freescale.com> wrote:
> > On 03/22/2013 08:08:57 AM, Peter Maydell wrote:
> >> The memory API flattens the tree of memory regions down into a flat
> >> view of the address space. These callbacks get called for the
> >> final flattened view (so you'll never see a pure container in the
> >> callback, only leaves). The callbacks happen for every region which
> >> appears in the address space, in linear order. When an update  
> happens
> >> memory.c identifies the changes between the old flat view and the
> >> new one and calls callbacks appropriately.
> >
> > OK, so .add and .del will be sufficient to capture any manipulation  
> that
> > would affect whether and where the region we care about is mapped?
> 
> Yes. Note that if the board (brokenly) maps the region so it is
> 'hidden' by another region, this manifests as a .del [since it
> is no longer accessible]. Also I think if the board maps something
> small on top and in the middle of the region you get an add for
> each of the partially visible fragments. Personally I'm happy to
> not worry about either of these cases

Yeah, if we do check for those cases it should just be to print an  
error.

> on the basis that they would be board model bugs.

In some cases it could be guest code doing something screwy, but if you  
need to support that then turn off the in-kernel pic.

> >> > The MPIC's memory listener isn't that much code... I'm not sure
> >> > there's a great need for a central KVM registry.
> >>
> >> Well, nor is the ARM memory listener, but why have two bits of
> >> code doing the same thing when you could have one?
> >
> > They're not doing quite the same thing, though, and the effort  
> required to
> > unify them is non-zero.  The two main issues are the way that the  
> address is
> > communicated to KVM, and the ability to change the mapping after  
> the guest
> > starts.
> 
> Ah, guest-programmable mappings are a real use case and not a  
> hypothetical?

It's real in terms of how the hardware works.  QEMU doesn't yet  
implement it, but it should, especially with Alex occasionally saying  
he'd like to see QEMU capable of running U-Boot.

> Do we run into synchronisation issues with making sure that QEMU and
> the kernel both agree simultaneously about where the mapping is?

I don't think so -- the guest CPU that is doing the moving is stopped  
for QEMU MMIO, and if the other CPUs try to access it in the meantime,  
it would be undefined even on real hardware whether it happens before  
or after the move takes effect.

> Can the mapping be different between different CPU cores? [let's
> hope not :-)]

Not in a way that's relevant here.  There's some per-cpu magic internal  
to the region, but that's handled within the kernel.

> Is the mapping controlled by a register within the
> mapping itself, or is there some separate non-moving register which
> defines the location of the mappable registers?

There's a separate moving register. :-P

MPIC is combined with a bunch of other devices into a large region  
called CCSR, and that region can be moved as a whole by writing to a  
register at the beginning of CCSR.

-Scott