qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Date: Sun, 20 Dec 2009 17:20:39 +0200
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/20/2009 05:11 PM, Anthony Liguori wrote:

Not at all. Reset can happen in a lot of different ways, some that there is really no way to detect (jumping right to BIOS vector). From a hardware perspective, powering down a CPU and powering it on again behaves very differently than reset (consider the VT enablement MSRs).

Power down and reset are equivalent, you're thinking of INIT (though some boards wire reset to INIT).

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.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]