KVM and OS/2: #UD in real mode

KVM and OS/2: #UD in real mode

[H. Peter Anvin]

Just for fun, I tried to boot OS/2 Warp 4.0 under KVM (KVM-59 with the 
latest git kernel from Linus as of yesterday, slightly post 2.6.24-rc8.) 
   I found that it crashes very early, apparently because KVM doesn't 
handle an #UD received in user mode.  It appears that OS/2 actually 
provokes an #UD deliberately in real mode, from the disassembly it looks 
like it's trying to probe for the 486 version of cmpxchg (which has a 
different opcode than the 586+ version.)

It looks like the kernel code filters out a very small number of 
real-mode exceptions, and does a KVM exit for all the other ones; the 
userspace code then unconditionally barfs.  This is presumably a 
temporary hack; what is the intended behaviour - for this to be handled 
in-kernel, or in userspace?

	-hpa

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: KVM and OS/2: #UD in real mode

[Avi Kivity]

H. Peter Anvin wrote:
> Just for fun, I tried to boot OS/2 Warp 4.0 under KVM (KVM-59 with the 
> latest git kernel from Linus as of yesterday, slightly post 2.6.24-rc8.) 
>    I found that it crashes very early, apparently because KVM doesn't 
> handle an #UD received in user mode.  It appears that OS/2 actually 
> provokes an #UD deliberately in real mode, from the disassembly it looks 
> like it's trying to probe for the 486 version of cmpxchg (which has a 
> different opcode than the 586+ version.)
>   

Strange, the manual lists 0f b0 and 0f b1 as compatible all the way back 
to the 486.  What opcode are you seeing?

> It looks like the kernel code filters out a very small number of 
> real-mode exceptions, and does a KVM exit for all the other ones; the 
> userspace code then unconditionally barfs.  This is presumably a 
> temporary hack; what is the intended behaviour - for this to be handled 
> in-kernel, or in userspace?
>   

In kernel.  I've never seen a #UD in real mode, that's why it isn't handled.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: KVM and OS/2: #UD in real mode

[H. Peter Anvin]

Avi Kivity wrote:
> H. Peter Anvin wrote:
>> Just for fun, I tried to boot OS/2 Warp 4.0 under KVM (KVM-59 with the 
>> latest git kernel from Linus as of yesterday, slightly post 
>> 2.6.24-rc8.)    I found that it crashes very early, apparently because 
>> KVM doesn't handle an #UD received in user mode.  It appears that OS/2 
>> actually provokes an #UD deliberately in real mode, from the 
>> disassembly it looks like it's trying to probe for the 486 version of 
>> cmpxchg (which has a different opcode than the 586+ version.)
>>   
> 
> Strange, the manual lists 0f b0 and 0f b1 as compatible all the way back 
> to the 486.  What opcode are you seeing?
> 

0F A6.  Was apparently used on A-step 486's.

Could also just be a nonsense opcode used for trapping, or something 
like that.

>> It looks like the kernel code filters out a very small number of 
>> real-mode exceptions, and does a KVM exit for all the other ones; the 
>> userspace code then unconditionally barfs.  This is presumably a 
>> temporary hack; what is the intended behaviour - for this to be 
>> handled in-kernel, or in userspace?
> 
> In kernel.  I've never seen a #UD in real mode, that's why it isn't 
> handled.
> 

Just was a bit surprised to note that it explicitly tests for a small 
number of traps, when all the traps can be taken in real mode (via the IVT.)

	-hpa

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: KVM and OS/2: #UD in real mode

[Bjørn Mork]

"H. Peter Anvin" <hpa@zytor.com> writes:
> Avi Kivity wrote:
>> H. Peter Anvin wrote:
>>> Just for fun, I tried to boot OS/2 Warp 4.0 under KVM (KVM-59 with the 
>>> latest git kernel from Linus as of yesterday, slightly post 
>>> 2.6.24-rc8.)    I found that it crashes very early, apparently because 
>>> KVM doesn't handle an #UD received in user mode.  It appears that OS/2 
>>> actually provokes an #UD deliberately in real mode, from the 
>>> disassembly it looks like it's trying to probe for the 486 version of 
>>> cmpxchg (which has a different opcode than the 586+ version.)
>>>   
>> 
>> Strange, the manual lists 0f b0 and 0f b1 as compatible all the way back 
>> to the 486.  What opcode are you seeing?
>> 
>
> 0F A6.  Was apparently used on A-step 486's.
>
> Could also just be a nonsense opcode used for trapping, or something 
> like that.
>
>>> It looks like the kernel code filters out a very small number of 
>>> real-mode exceptions, and does a KVM exit for all the other ones; the 
>>> userspace code then unconditionally barfs.  This is presumably a 
>>> temporary hack; what is the intended behaviour - for this to be 
>>> handled in-kernel, or in userspace?
>> 
>> In kernel.  I've never seen a #UD in real mode, that's why it isn't 
>> handled.
>> 
>
> Just was a bit surprised to note that it explicitly tests for a small 
> number of traps, when all the traps can be taken in real mode (via the IVT.)

This is just to register myself as an user interested in a fix for OS/2
guests.

I wrote a few small OS/2 utilities more than a decade ago, and do still
get some requests for fixes or enhancements from OS/2 users. Yes, they
still exist :-)

However, I haven't had an OS/2 system myself in years and therefore
cannot provide much assistance.  But I still got the disk images and
would love to be able to boot it in KVM.

I did try to understand your discussion above, thinking that I might be
of some assistance, but I'm afraid it's waaaay over my head.  Therefore
I decided to just make this little note of interest.

This is the output I get from KVM-62 when trying to boot the original
OS/2 Warp 4 install floppy:

bjorn@canardo:~$ kvm -hda x.img -fda disk0.dsk -boot a                                 
exception 6 (0)
rax 00000000001e0000 rbx 00000000ffea0018 rcx 000000000000ff00 rdx 0000000000010000
rsi 0000000000000100 rdi 0000000000000280 rsp 0000000000009fec rbp 0000000000000439
r8  0000000000000000 r9  0000000000000000 r10 0000000000000000 r11 0000000000000000
r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000
rip 00000000000072e1 rflags 00233046
cs 1000 (00010000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
es 0400 (00004000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
ss 9400 (00094000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
fs 0400 (00004000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
tr 0000 (09400000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
gdt 9c0af/2f
idt 0/3ff
cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
code: bb 18 00 66 ff 37 c7 07 f1 72 8c 4f 02 33 c0 8b d0 b9 00 ff --> 0f a6 ca 90 90 90 90 90 f9 e3 01 f8 66 8f 07 c3 67 c7 04 24 ec 72 cf 33 c0 8e d8 bb 04 00
Aborted


I assume the "0f a6" here is the opcode you are talking about.


Bjørn
-- 
You're probably lesbian yourself


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/