Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to xenstore

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 13:08 +0000, Stefano Stabellini wrote:
> > On Thu, 19 Jan 2012, Ian Campbell wrote:
> > > On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> > > > Write to xenstore any physmap changes so that the hypervisor can be
> > > > aware of them.
> > > 
> > > What is the structure of the xenstore values? Looks like 
> > >   <domid>/physmap/<original-addr>/start_addr <new-addr>
> > > ?
> > 
> > Yep, that is the structure
> > 
> > 
> > > Who defines the meaning of original-addr, in particular what happens
> > > if it the original-addr for a device changes in a N->N+1 migration? What
> > > happens if things overlap or if a subsequent call only updates part of a
> > > previously moved mapping?
> > 
> > In practice it cannot happen because on restore Qemu is going to emulate
> > the same set of devices it was emulating before.
> > The original address is not going to change if the devices and the
> > amount of guest memory stay the same.
> 
> If you are migrating to a newer qemu then the <original-addr> could in
> principal change, I think.

Not unless the implementation of qemu_ram_alloc_from_ptr or
find_ram_offset change, but these are core qemu functions.
Or the device starts allocating more memory of course, but it wouldn't
be the same device anymore.
In any case, if we also match on the MemoryRegion name we cannot go
wrong.


> > We could add some additional info to better identify the physmap entry,
> > probably the best we could use is the memory_region name.
> 
> And/Or the PCI BDF + BAR?

I don't think we can get the PCI BDF from the Xen MemoryListener, but we
can get the MemoryRegion. The most identifying info in it I think is the
name, for example for vga would be "vga.vram".

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel