Re: qemu oddness with isolinux vesamenu.c32

Re: qemu oddness with isolinux vesamenu.c32

[H. Peter Anvin]

[Resend corrected destinations]

H. Peter Anvin wrote:
>>
>> hope this helps
> 
> Cc: the kvm-devel list in the hope that they might be able to shed some 
> light on this.
> 
> What this means is that an expansion ROM located in the ISA expansion 
> area at segment D000 tried to call the DOS interrupt INT 2Ch with 
> AX=42C4h.  I believe INT 2Ch is a no-op in DOS, but does something in 
> the NT kernel.
> 
> The CS:IP of the call was D000:04F0.
> 
> I have no idea what would do this; nothing in the command line list 
> stands out as anything which would install an expansion ROM image into 
> the VM.
> 
> Either way, it would be good to find out what the idea of calling INT 
> 2Ch here is.
> 

Never mind, I tracked it down; it's the extboot extension to KVM.

         /* save old int 19 at int 2b */
[...]
         /* save old int 13 to int 2c */

This is highly unsafe behaviour, *especially* given the choice of
vectors (int 20-3f are used by any DOS-like operating system, and
Syslinux uses them for compatibility with DOS.)

Some BIOSes do this kind of things, but they use vectors in the range
0xc0-0xef.  The use of these vectors is platform-dependent, but since
KVM controls the platform, that is relatively safe.

Furthermore, it is completely unnecessary.  Instead of stuffing the old
pointer in an interupt vector and using the INT instruction, stuff it in
a variable in the local code segment, and use the following sequence:

	pushf
	lcallw *%cs:old_vector

In order to do this it needs, of course, to be able to write to its own
memory, which I'm not sure if qemu-kvm allows by default.  If so, this
is actually a defect in qemu-kvm, since modern expansion "ROMs" *do*
expect to be able to write to their own memory areas during
initialization; see the PnPBIOS spec, Appendix B; support for this
specification is mandatory for PCI systems.

	-hpa

Re: qemu oddness with isolinux vesamenu.c32

[H. Peter Anvin]

Just noticed this post was missing the initial information:

<mdomsch> hpa: your test ISO shows:  vesamenu.c32: attempted DOS system 
call INT 2C 42C4 D00004F0
<mdomsch> when run under latest F9 virt-manager started KVM machine
<mdomsch> hpa, but does _not_ fail as such when run manually with
<mdomsch> sudo qemu-kvm -M pc -m 512 -hda 
/var/lib/libvirt/images/hpa.img -cdrom /var/tmp/boot-fc9-3.70-pre26.iso
<mdomsch> hpa, which means one of these args is probably causing it
<mdomsch> /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name foo -monitor 
pty -boot c -drive 
file=/var/lib/libvirt/images/foo.img,if=ide,index=0,boot=on -drive 
file=,if=ide,media=cdrom,index=2 -net 
nic,macaddr=00:16:3e:13:75:3a,vlan=0 -net 
tap,fd=13,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb 
-vnc 127.0.0.1:0 -k en-us



For what it's worth, it's the "boot=on" part that is causing extboot to 
be invoked, which is what is causing the failure.

I have to admit I don't really understand why extboot hooks INT 13h at 
all (why emulate a disk on a system where disks are virtual anyway?), 
but more seriously, it has the problem that:

a) it uses vectors in OS reserved space;
b) it doesn't clean up after itself after giving up and before invoking
    the old INT 19h vector.

	-hpa

Re: qemu oddness with isolinux vesamenu.c32

[Avi Kivity]

H. Peter Anvin wrote:
>
> Furthermore, it is completely unnecessary.  Instead of stuffing the old
> pointer in an interupt vector and using the INT instruction, stuff it in
> a variable in the local code segment, and use the following sequence:
>
>     pushf
>     lcallw *%cs:old_vector
>
> In order to do this it needs, of course, to be able to write to its own
> memory, which I'm not sure if qemu-kvm allows by default.  If so, this

You mean, "if not"?

> is actually a defect in qemu-kvm, since modern expansion "ROMs" *do*
> expect to be able to write to their own memory areas during
> initialization; see the PnPBIOS spec, Appendix B; support for this
> specification is mandatory for PCI systems.
>

kvm allows writing into the bios; qemu does not.  I thought it was a kvm 
bug, but turns out that it's a qemu bug...

(though to be fair, true emulation ought to start out read-only, then be 
enabled by the bios ram shadow mechanism)

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: qemu oddness with isolinux vesamenu.c32

[H. Peter Anvin]

Avi Kivity wrote:
> 
> kvm allows writing into the bios; qemu does not.  I thought it was a kvm 
> bug, but turns out that it's a qemu bug...
> 
> (though to be fair, true emulation ought to start out read-only, then be 
> enabled by the bios ram shadow mechanism)
> 

Yes, although simulating the memory "pre-shadowed" works just as well; 
then it should be marked readonly by the BIOS immediately prior to 
running INT 19h.

	-hpa

Re: qemu oddness with isolinux vesamenu.c32

[H. Peter Anvin]

H. Peter Anvin wrote:
> 
> Yes, although simulating the memory "pre-shadowed" works just as well; 
> then it should be marked readonly by the BIOS immediately prior to 
> running INT 19h.
> 

On top of this, getting proper DDIM support and PCI expansion ROM into 
the BIOS would be a good thing.  A PCI expansion ROM is attached to a 
PCI device as a BAR and mapped into high memory, it is then copied to 
shadowed RAM by the BIOS and its initialization stub is run.  This is 
done one device at a time, so that the initialization code can be 
discarded, per the DDIM spec.

	-hpa

Re: qemu oddness with isolinux vesamenu.c32

[Avi Kivity]

H. Peter Anvin wrote:
> H. Peter Anvin wrote:
>>
>> Yes, although simulating the memory "pre-shadowed" works just as 
>> well; then it should be marked readonly by the BIOS immediately prior 
>> to running INT 19h.
>>
>
> On top of this, getting proper DDIM support and PCI expansion ROM into 
> the BIOS would be a good thing.  A PCI expansion ROM is attached to a 
> PCI device as a BAR and mapped into high memory, it is then copied to 
> shadowed RAM by the BIOS and its initialization stub is run.  This is 
> done one device at a time, so that the initialization code can be 
> discarded, per the DDIM spec.

I imagine it's necessary for proper pci device assignment.

-- 
error compiling committee.c: too many arguments to function

Re: qemu oddness with isolinux vesamenu.c32

[H. Peter Anvin]

Avi Kivity wrote:
> H. Peter Anvin wrote:
>> H. Peter Anvin wrote:
>>>
>>> Yes, although simulating the memory "pre-shadowed" works just as 
>>> well; then it should be marked readonly by the BIOS immediately prior 
>>> to running INT 19h.
>>
>> On top of this, getting proper DDIM support and PCI expansion ROM into 
>> the BIOS would be a good thing.  A PCI expansion ROM is attached to a 
>> PCI device as a BAR and mapped into high memory, it is then copied to 
>> shadowed RAM by the BIOS and its initialization stub is run.  This is 
>> done one device at a time, so that the initialization code can be 
>> discarded, per the DDIM spec.
> 
> I imagine it's necessary for proper pci device assignment.
> 

Well, if nothing else it would permit PCI device ROMs to work 
unmodified.  I was rather disappointed when I found out I couldn't 
simulate PXE ROMs, even from devices which we can emulate.

	-hpa