qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Date: Sun, 20 Dec 2009 09:11:18 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No.  You have to physically shut down and start up again.  That's
the right semantics IMHO.

Reset is equivalent (or should be) to shut down and start up again.

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

Second what if ROM size have changed (on destination it is
smaller)?
Then we're in trouble :-)
Yeah, we are. May be relaying on file size is not good enough heuristic
to determine ROM BAR size.

Practically speaking, I don't think it's a huge problem to be honest. It's a very unlikely scenario. We could make the rom size a qdev property which would allow a user to explicitly deal with this case.

But the fw_cfg rom loading doesn't seem handle migration :-/

Looks like it. We should send them over during migration too.

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.

Regards,

Anthony Liguori




reply via email to

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