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: Gleb Natapov
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Date: Sun, 20 Dec 2009 17:23:46 +0200

On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
> 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
We support only one way of reset: hard reset. It equivalent to full
HW power cycling. ACPI spec define ACPI reset as equivalent to HW power
cycling too BTW (see 4.7.3.6).

> there is really no way to detect (jumping right to BIOS vector).
This is not reset at all from qemu POV. No need to reload ROMS.
 
> From a hardware perspective, powering down a CPU and powering it on
> again behaves very differently than reset (consider the VT
> enablement MSRs).
May be you are confusing cpu reset by INIT with CPU reset by power
cycling. system_reset (or triple fault or kbd reset or ACPI reset)
does the later.

> 
> >>>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.
Agree that it is unlikely, but I don't want to be the one debugging it.

> 
> >>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.
> 
This will work only if we assume that rom file size doesn't shrink, 

--
                        Gleb.




reply via email to

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