|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. |
Date: | Tue, 22 Dec 2009 09:11:01 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 |
On 12/22/2009 07:04 AM, Paul Brook 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.Ram allocations should be associated with a device. The VMState stuff this should make this fairly straightforward.
Right, but for the sake of simplicity, you don't want to treat that ram any differently than main ram wrt live migration. That's why I proposed adding a context id for each ram region. That would allow us to use something like the qdev name + id as the context id for a ram chunk to get that association while still doing live ram migration of the memory.
Guest address space mappings are a completely separate issue. The device should be migrating the mappings (directly or via a PCI BAR) as part of its state migration. The ram regions might not be mapped into guest address space at all.
We don't migrate guest address space memory today. We migrate anything that's qemu_ram_alloc()'d. The big problem we have though is that we don't have any real association between the qemu_ram_alloc() results and what the context of the allocation was. We assume the order of these allocations are fixed and that's entirely wrong.
For non-device qemu_ram_alloc()'s, we could either create essentially dummy ram devices or we could just special case it.
Regards, Anthony Liguori
Paul
[Prev in Thread] | Current Thread | [Next in Thread] |