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

[Avi Kivity <avi@xxxxxxxxxx>]

On 01/19/2012 04:16 PM, Stefano Stabellini wrote:
> > 
> > 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.

Both of these functions will be removed.  There will no longer be a
qemu-internal address space for physical memory; instead memory will be
addressed using a (MemoryRegion, offset) pair.

We can/will hook memory_region_init_ram() to call xen_ram_alloc() which
can then generate those old addresses, but those (like qemu_ram_alloc())
are dependent on allocation order and you shouldn't depend on them
returning stable values.

> 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.

Match on just the MemoryRegion (and match on the object itself, not the
name; see xen_register_framebuffer()).

> > > 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".


-- 
error compiling committee.c: too many arguments to function


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