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