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

[Avi Kivity <avi@redhat.com>]

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