Hi Hai,

Guessing Gerd could be busy on working for the fix, so asking you instead :-)

I've read the upstream discussion, and saw that the origin report was using a 16 bit app.

This it's a very very corner use case today in my point of view.
Using 16 bit app today is weird. it's not possible to run on 64 bit OS, and RHEL7 also dont ship with a 32 compose.

For test coverage,
I checked our existing test cases for KVM, seeing that there's no a case for 16 bit app or real mode except SeaBIOS PXE test(and it's still partial real mode).

My questions:
1) is there any necessity to add test case for this kind of corner usage ?
    from my pov, no.
    even 32 bit is considered to be legacy in the near future.
    if the industry majorly adopt UEFI(which we tech preview for x64 now),
    then using 16 bit app in guest would be no possible to run natively.


2) if you think there's necessary, would you pls provide a unit case for KVM ?
    the origin report was on a private app, we even dont know the name.
    Though mail list tells Skifree could also trigger, but that is a Windows app
    which could not cover Linux guest OS, so if there's need for test case,
    a dedicated unit test would be nice.


Thanks,
Xiaoqing.

patches posted.

  Hi,

> 1) is there any necessity to add test case for this kind of corner usage ?
>     from my pov, no.

I'd say not for now.  Maybe we can create one once the root cause has been figured in the upstream discussions.

Fix included in seabios-1.7.5-8.el7

Created attachment 982613 [details]
seabios-vga-1.7.5-6.png

on seavgabios-bin-1.7.5-6

Skifree(16 bit) stops responding after double click to start the game.

Created attachment 982614 [details]
seabios-vgabios-1.7.5-8.png

with seavgabios-bin-1.7.5-8

Skifree(16 bit) could run, it's not that joyful,
but runs smoothly, and unlike -6 version would stop responding.
observed for 5mins. I'll keep this app opened in guest to see if it survives longer.

Hi Gerd,

I think C#8 and C#9 should fine for verify this bz ?

Best Regards,
Xiaoqing Wei.

three vga types tested:
cirrus, std, qxl
cli as below

/bin/qemu-kvm \
    -S  \
    -name 'virt-tests-vm1'  \
    -sandbox off  \
    -M pc  \
    -nodefaults  \
    -vga std  \           -> and switched to cirrus, or qxl
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20150122-152837-LsTJiyoF,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150122-152837-LsTJiyoF,server,nowait \
    -device isa-serial,chardev=serial_id_serial0  \
    -chardev socket,id=seabioslog_id_20150122-152837-LsTJiyoF,path=/tmp/seabios-20150122-152837-LsTJiyoF,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20150122-152837-LsTJiyoF,iobase=0x402 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2008-sp2-32-virtio.qcow2 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
    -device virtio-net-pci,mac=9a:8c:8d:8e:8f:90,id=id8Xokyp,vectors=4,netdev=idl2liRz,bus=pci.0,addr=05  \
    -netdev tap,id=idl2liRz,vhost=on,vhostfd=24,fd=23  \
    -m 4096  \
    -smp 4,maxcpus=4,cores=2,threads=1,sockets=2  \
    -cpu 'SandyBridge',hv_relaxed,+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
    -drive id=drive_cd1,if=none,snapshot=off,aio=native,media=cdrom,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/isos/windows/winutils.iso \
    -device ide-cd,id=cd1,drive=drive_cd1,bootindex=1,bus=ide.0,unit=0 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -vnc :1  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm

> I think C#8 and C#9 should fine for verify this bz ?

Yes.

(In reply to Gerd Hoffmann from comment #12)
> > I think C#8 and C#9 should fine for verify this bz ?
> 
> Yes.

Cool, moving to VERIFIED.

Thanks.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0345.html