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

[Jamie Lokier <jamie@shareable.org>]

Gleb Natapov wrote:
> 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.

Some software expects it.  But the worst situation is when it's
"mostly reliable", i.e. works normally but unreliable if migration
occurs during the reset cycle.  It should either be reliable, or if
that is not intended, the memory should be wiped on reset to be sure
nobody is running guests which depend on it.  (They might not even know).

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

Reminder about x86 HW emulation; recent message:

http://www.mail-archive.com/qemu-devel@nongnu.org/msg22676.html

TAKEDA, toshiya wrote:
> Anthony Liguori wrote:
> >Hi,
> >
> >Why is this needed verses qemu_system_reset()?
> 
> PC-98 has the ioport to reset only cpu (don't reset other periferals) 
> and I need qemu_cpu_reset() to emulate thios port.
> 
> This port was used to return to real mode from protect mode by resetting cpu.
> It was added for 80286, but was used on PC-98 with 80386 and later.
> (For example for checking of over 1mb memory in hardware
> initialization bios.)
> 
> Thanks,
> TAKEDA, toshiya

That is, PC-98 emulation requires a CPU-only reset that retains memory
contents and does not reset peripherals.  It has an I/O port
explicitly for it.

Regular x86 PCs also require this under some circumstances, for the
same reasons: To run 80286 MS-DOS software (on a later CPU of course
:-) that switches from protected mode to real mode by triggering a
hardware reset.  It does not reset the peripherals and memory contents
are reliable, except possibly for some regions that the BIOS may affect.

I assume this was one of the things meant in Anthony's qemu 0.12
release announcment:

>>> [please test...]
>>> - exotic x86 guests that may interact with the BIOS in special ways

But I don't really understand

  - what strange things are being implemented with ROMs changing on
    boot and during migration
  - how it depends in some intricate way on ACPI tables and option ROMS
    and migration and qemu upgrades all at once
  - those are things which the "exotic" guests don't care about
  - memory is preserved, isn't it, when qemu resets, even though it is
    called "not reliable", meaning that test guests will run fine with
    it while having some hidden bug waiting to happen under a rare
    conjunction of qemu's circumstances - is that right?

So I don't know quite what to test to confirm or deny bugs in
emulation of things that exotic x86 guests depend on.

-- Jamie