Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

[Avi Kivity]

On 12/20/2009 05:31 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
> > > We should just qemu_ram_alloc() that memory regardless of whether we 
> > > every map it into the guest.  Since roms can be large, we want to 
> > > send their contents over during the live part of migration.  If we 
> > > use qemu_ram_alloc(), we get that for free.
> >
> > Currently live migration uses ram_addrs, so this would work.  But 
> > ram_addrs have no meaning in the guest and thus depend on qemu 
> > implementation details.  IMO we should switch live migration to use 
> > guest physical addresses, which would require a different migration 
> > implementation for roms.  Most of it can be shared with ram, though.
>
> I'd rather do (id, offset) instead of guest physical address.  Guest 
> physical addresses map to ram_addrs in chunks.  Each chunk usually has 
> some reasonable identification (below 640k, above 1mb, above 4gb, 
> etc.).  Other type of memory like roms and vga lfb memory aren't 
> always part of the guest physical address space but nonetheless still 
> need to be migrated.  This gives us one mechanism to support everything.

What about hotplugged memory?  I guess we can introduce the notion of 
user-visible memory slots; those exist on real hardware as well.  These 
slots would be different from the kvm memory slots, of course.

ids do have a nice property in that pci memory can be migrated while its 
BAR changes.  With gpa you'd need special handling.

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