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:33:47 +0200

On Sun, Dec 20, 2009 at 09:28:34AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >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).
> 
> For every system periphereal?
To cite ACPI spec : "From an OSPM perspective, asserting the reset mechanism
is the logical equivalent to power cycling the machine."

>                                For instance, memory contents survive
> a reset whereas they won't survive a hard power down.
> 
We cannot rely on memory content after such reset.

> More importantly though, what's the use-case here?
> 
Use-case for what? This just what need to be done for correct HW
emulation.

> >This will work only if we assume that rom file size doesn't shrink,
> 
> Well the easy thing to do is hard code the rom size into qemu and
> throw an error if the rom size increases.  That way, if a rom does
> shrink, we're safe and if a rom size increases, we get an immediate
> run time error that gives the contributor feed back that they need
> to bump the constant.
> 

--
                        Gleb.




reply via email to

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