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

login
register
mail settings
Submitter Laszlo Ersek
Date Feb. 15, 2013, 6:54 p.m.
Message ID <511E8470.1020707@redhat.com>
Download mbox | patch
Permalink /patch/220807/
State New
Headers show

Comments

Laszlo Ersek - Feb. 15, 2013, 6:54 p.m.
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
David Woodhouse - Feb. 15, 2013, 8:57 p.m.
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
Laszlo Ersek - Feb. 16, 2013, 1:37 a.m.
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
David Woodhouse - Feb. 18, 2013, 10:40 a.m.
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...

Patch

--- dwmw2.log   2013-02-15 18:47:39.654360652 +0100
+++ lersek.log  2013-02-15 18:49:18.061364128 +0100
@@ -1,18 +1,12 @@ 
-enter handle_13:
-   a=00004200  b=00000801  c=0000003f  d=00000080 ds=6000 es=0000 ss=0000
-  si=0000fe00 di=00000000 bp=00001ff0 sp=00001ff2 cs=0000 ip=9157  f=0202
-disk_op d=0x0000db20 lba=9269505 buf=0x00068000 count=63 cmd=2
-pmtimer: 2:15494096
-pmtimer: 2:15494211
+enter handle_15:
+   a=00002401  b=00004118  c=00000000  d=00000003 ds=0000 es=4000 ss=4000
+  si=00000000 di=00004380 bp=00000000 sp=0000ffc6 cs=4f00 ip=0030  f=3002
+Trying to allocate 971 pages for VMLINUZ
+[Linux-EFI, setup=0x10fa, size=0x3ca030]
+   [Initrd, addr=0x3c089000, size=0xf68cb9]
+\u02d9Changing serial settings was 0/0 now 3/0
 In resume (status=0)
 In 32bit resume
 Attempting a hard reboot
 i8042_wait_write
-pmtimer: 2:15501497
-pmtimer: 2:15501593
-pmtimer: 2:15501750
-SecCoreStartupWithStack(0xFFFE6000, 0x80000)
-File->Type: 0xB
-Section->Type: 0x2
-Section->Type: 0x19
-Section->Type (0x19) != SectionType (0x17)
+Changing serial settings was 0/0 now 3/0