(PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

On 02/14/13 23:24, David Woodhouse wrote:
> On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
>> I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
>> reset requested by the guest doesn't work as expected. The behavior is
>> an infinite loop, with the following debug fragment repeated by the
>> CSM-ized SeaBIOS:
>>
>>   In resume (status=0)
>>   In 32bit resume
>>   Attempting a hard reboot
>>   i8042_wait_write
> 
> Hmm. My build from http://david.woodhou.se/OVMF.fd works fine. I did a
> legacy boot into (Ubuntu Oneiric's) Grub, then issued the 'reboot'
> command...
> 
> This appears to be the case for qemu 1.2.0 and 1.3.0, both with and
> without KVM.

I retested:
- on a pristine v3.0.0 host kernel, and
- a pristine v1.3.1 qemu build (+ KVM enabled), and
- using your OVMF.fd from the above link (which of course includes your
  build of the CSM-ized SeaBIOS).

Same infinite loop, alas...

(i) What is your host kernel exactly?

(ii) And when you say you did a "legacy boot", does that mean you installed
the guest OS as a traditional one? Is that grub or grub-efi?

In my case the guest is a "full" UEFI installation of RHEL-6: I perform
an UEFI boot from an emulated IDE disk to load grub-efi (which is thus
pointed to by a non-BBS-devpath). The only thing I'm using the CSM for
is the GOP based on vgabios-cirrus.bin

(iii) Can vgabios.bin make a difference? Could you please upload your build? I
gather you use stdvga; I also tried that, makes no difference, same
loop.

Comparing our logs,

[...]

Thanks
Laszlo

On Fri, 2013-02-15 at 19:54 +0100, Laszlo Ersek wrote:
> Same infinite loop, alas...
> 
> (i) What is your host kernel exactly?

3.7.5-201.fc18.x86_64 (booted from EFI on a MacBookPro 8,3).

> (ii) And when you say you did a "legacy boot", does that mean you installed
> the guest OS as a traditional one? Is that grub or grub-efi?

That one was a traditional install. I've just now tested an EFI install
of Fedora 17, which also reboots fine; both from grub and the installed
kernel. It *doesn't* seem to hit the SeaBIOS CSM on the way back, but
reboots directly into OVMF.

I have two versions of qemu; the Fedora 18 one (1.2.0) and a
locally-rebuilt copy of the Fedora rawhide 1.3.0, which I installed
because OVMF's native video driver doesn't work in 1.2.0. Not that that
matters any more since I've disabled that and I'm using the VGA BIOS.

There's also a current build from qemu git. They all behave the same
way, both with and without KVM.

> (iii) Can vgabios.bin make a difference? Could you please upload your build? I
> gather you use stdvga; I also tried that, makes no difference, same
> loop.

This shouldn't make a difference. For the old vgabios, I only have the
alignment fix, and no video would work if you didn't have that.
http://david.woodhou.se/vgabios-cirrus.bin

On 02/15/13 21:57, David Woodhouse wrote:
> On Fri, 2013-02-15 at 19:54 +0100, Laszlo Ersek wrote:
>> Same infinite loop, alas...
>>
>> (i) What is your host kernel exactly?
>
> 3.7.5-201.fc18.x86_64 (booted from EFI on a MacBookPro 8,3).

- host CPU: Xeon W3550 (family/model/stepping = 6/26/5)

- host kernel: 3.7.8; config attached

- md5sums of firmware binaries (both from you):

  61daae4d085f646093e31df2b13b13e8  OVMF-david.fd
  3a6a829c55cbd4e27db745326a5fed44  vgabios-cirrus-david.bin

- qemu: upstream v1.3.1; configs attached

  ./configure --target-list=x86_64-softmmu --prefix=/opt/qemu-upstream \
  --enable-debug

- libvirt XML: attached; <emulator> refers to qemu wrapper script

- qemu command line (from ps -f):

  /opt/qemu-upstream/bin/qemu-system-x86_64 \
  -name fw-mixed.g-f18xfce2012121716.e-upstream \
  -S \
  -M pc-1.3 \
  -enable-kvm \
  -bios /root/OVMF-david.fd \
  -m 1024 \
  -smp 4,sockets=4,cores=1,threads=1 \
  -uuid 0865a1c1-6474-249b-5e84-81171c4e1d0c \
  -no-user-config \
  -nodefaults \
  -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fw-mixed.g-f18xfce2012121716.e-upstream.monitor,server,nowait \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=utc \
  -no-shutdown \
  -boot c \
  -drive file=/var/lib/libvirt/images/fw-mixed.g-f18xfce2012121716.e-upstream.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none \
  -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 \
  -drive file=/filestore/isos/f18/Fedora-18-Nightly-20121217.16-x86_64-Live-xfce.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw \
  -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \
  -chardev pty,id=charserial0 \
  -device isa-serial,chardev=charserial0,id=serial0 \
  -usb \
  -vnc 127.0.0.1:0 \
  -vga cirrus \
  -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
  -debugcon file:/tmp/fw-mixed.g-f18xfce2012121716.e-upstream.debug \
  -global isa-debugcon.iobase=0x402 \
  -global PIIX4_PM.disable_s3=0 \
  -global PIIX4_PM.disable_s4=0

- guest: F18 XFCE nightly, UEFI installed, UEFI booted

- serial output: attached

- result: infinite loop at guest reset

I give up. Thanks for the help & sorry about spamming three lists.

Laszlo

On Sat, 2013-02-16 at 02:37 +0100, Laszlo Ersek wrote:
> I give up. Thanks for the help & sorry about spamming three lists.

I've managed to reproduce this on a clean F18 system. This is the stock
qemu 1.2.2-6.fc18 on kernel 3.7.6-201.fc18.x86_64 with a newly-installed
Fedora 18 VM in the guest.

qemu-system-x86_64 -enable-kvm -cdrom F18boot.iso -serial mon:stdio -bios OVMF.fd

On my laptop where I'd been doing most of my testing, even after running
'yum distro-sync qemu\*' to get back to the stock qemu, I still can't
reproduce the issue. They are both running the *same* kernel.

I'll try reverting a whole bunch of other stuff that ought to be
irrelevant to the stock distro packages, and see if/when it breaks...