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

[David Woodhouse]

On Thu, 2013-02-21 at 00:50 +0100, Laszlo Ersek wrote:
> On 02/20/13 19:12, Anthony Liguori wrote:
> 
> > Or better yet, post binaries of Tiano Core + SeaBIOS as a CSM for me to
> > try out?
> 
> I tested David's recent PAM-resetting series with these:
> 
> http://people.redhat.com/~lersek/csm-test.tar.xz
> 
> (Debug output of OVMF, SeaBIOS and SeaVGABIOS all goes to the qemu debug
> console; -debugcon file:XXXX -global isa-debugcon.iobase=0x402.)

Oops, sorry for not noticing that request earlier.

> > 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 :)

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

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...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature