KVM and OS/2: #UD in real mode
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/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · 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.)
Strange, the manual lists 0f b0 and 0f b1 as compatible all the way back to the 486. What opcode are you seeing?
Quoted 6 lines
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.
Signature · 7 lines
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/
A message that is not in the archive (sent off-list or not yet received): 4798312D.9060204-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 10 lines · Avi Kivity
Quoted 8 lines · 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.)
Quoted 3 lines
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.
Quoted 9 lines
Quoted 5 lines
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/
Quoted 26 lines · H. Peter Anvin
Quoted 10 lines · Avi Kivity
Quoted 8 lines · 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.)Quoted 3 lines
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.
Quoted 6 lines
Quoted 5 lines
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?
Quoted 6 lines
Quoted 3 lines
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
Signature · 7 lines
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/