Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types

[Laszlo Ersek]

On 02/21/13 00:55, David Woodhouse wrote:

>>> The above implements a CPU-only soft reset that should fix the problem
>>> you're having with PAM resetting unconditionally.  If it works, I'll
>>> fixup the other PC callers of reset too.
>>
>> The problem I was facing on my workstation is that the PAM registers
>> were *not* reset, unconditionally. What I needed was KVM continuing at
>> 0xfffffff0, or to make the reset "as hard as possible": it was "too
>> soft". So if the linked branch makes resets softer, that's the opposite
>> direction for my problem.
>
> Well... your test now works because of the bug that Anthony is trying to
> fix :)

I don't believe so,

> SeaBIOS is doing a keyboard-controller reset. And that's supposed to be
> a soft reset and thus *shouldn't* reset the PAM configuration.

the reset I tested was requested by the Linux kernel (in one of the ways
we discussed elsewhere). Granted, one of those methods may have been a
keyboard-controller reset.

I booted Fedora 18 from OVMF+SeaBIOS CSM to the xfce GUI, then clicked
Reboot on the virt-manager window. That generates an ACPI event, which
starts the shutdown sequence, at the end of which the kernel reboots the
VM. SeaBIOS cannot come into the picture until after that Linux request.
(And if the host machine supports unrestricted guest, or the host kernel
has a very recent KVM, or qemu resets the PAMs, then SeaBIOS doesn't
come into the picture at all, at least before OVMF invokes again it
after reboot.)

> We need to fix SeaBIOS to do a "PCI" (0xcf9) reset. Or, since SeaBIOS
> isn't supposed to be hardware-specific, we need to fix SeaBIOS to use
> the ACPI RESET_REG, and fix OVMF to *set* the RESET_REG in the ACPI
> tables it generates. I posted patches for the SeaBIOS side of that
> today, if you want to do the OVMF side...

(adding Jordan & edk2-devel)

We might want to discuss two things here:

(1) The reset capability that OVMF exports via ACPI -- I agree that I
should be effecting the 0xCF9 thing in the appropriate table.

(2) There's also one point (that I've ever seen) where OVMF itself
resets the platform. It is on the initial config TUI; there's a Reset
System option somewhere.

... It's implemented in
"IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.c",
function BootMaintCallback(). It calls

      gRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);

This runtime service comes from "PcAtChipsetPkg/KbcResetDxe" for
OvmfPkg, which delegates the task to whichever ResetSystemLib flavor the
module being built specifies. For OvmfPkg that's
"OvmfPkg/Library/ResetSystemLib", and for a cold reset it uses

  /**
    Calling this function causes a system-wide reset. This sets
    all circuitry within the system to its initial state. This type of reset
    is asynchronous to system operation and operates without regard to
    cycle boundaries.

    System reset should not return, if it returns, it means the system does
    not support cold reset.
  **/
  VOID
  EFIAPI
  ResetCold (
    VOID
    )
  {
    IoWrite8 (0x64, 0xfe);
  }

The same code is used for ResetWarm(), this is the keyboard reset.

I guess I could change it to access 0xCF9 instead, but
- that won't work on earlier qemu versions,
- it turns the intermediate module "PcAtChipsetPkg/KbcResetDxe" a
misnomer, since we wouldn't be using the keyboard controller any longer.
(Actually, in theory, "KbcResetDxe" itself is incapable of hard reset.)

OTOH if the keyboard reset gets soft in qemu, then OVMF's hard reset
(the above code) will break. Maybe I could cycle between 0xCF9 and 0x64
in ResetCold(), starting with 0xCF9. (The full logic in the Linux kernel
seems a bit too much, see the list of source files in
<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2093/focus=195441>.)


((3) Apparently a pre-DXE reset service (PPI,
Pre-EFI-Initialization-Module to Pre-Efi-Initialization-Module
Interface) exists as well, called PeiResetService(). It tries to
delegate to the architectural protocol designated with
"gEfiPeiResetPpiGuid" (MdeModulePkg/Core/Pei/Reset/Reset.c). The
protocol has one function of type EFI_PEI_RESET_SYSTEM ("This service
resets the entire platform, including all processors and devices, and
reboots the system"), but it doesn't seem to be implemented anywhere in
edk2. It's documented in Volume 1, Chapter 4.8 of the Plat. Init. Spec.
We probably don't need to provide it.)

Laszlo