VMX Assist and x86 segment registers

VMX Assist and x86 segment registers

[Randy Thelen]

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

Executive summary --

If you're interested in running FreeBSD in an HVM domain on VT-x  
hardware, please EXPERIMENT with the attached patch.  However, the  
patch is not in and of itself a fix.  I'm simply looking for more  
help on solving this bigger problem and pushing the patch to the Xen  
community is the best way I could think of to get more insight into  
the problem.

If you're still interested, please continue reading.

Folks --

Here's an esoteric topic: x86 segment registers and their emulation  
with vmxassist.  Anybody interested in engaging in this one? ;-)

Here's the story.  FreeBSD doesn't boot on Intel processors with VT-x  
hardware in an HVM domain.  It turns out I'm dependent upon that  
functionality.  So, I began to investigate.  Dragons lie in them thar  
hills.  (Snakes, spiders, whatever: I -hate- segmentation and I - 
hate- segment registers.  So you can imagine the frustration I had as  
I realized I needed to become intimately familiar with them to solve  
my problem.)

Here's the deal, the x86 processor allows segment registers to be set  
in one mode (e.g., "real mode") and the used in another mode (e.g.,  
"protected mode").  For an example of how this trick is utilized,  
peruse subject 15:  Accessing 4 Gigs of Memory in Real Mode:

http://www.cs.uu.nl/wais/html/na-dir/assembly-language/x86/general/ 
part2.html

(Be prepared to be completely disgusted.)

At any rate, between my own debugging and reading articles of the  
sort above, I realized that vmxassist was incorrectly handling  
segment registers.

I've made a patch that I've attached but I am -NOT- recommending this  
for general consumption.  This patch is -ONLY- recommended for those  
who want to run FreeBSD on VT-x hardware and those who are willing to  
work through additional bugs to solve interesting problems.  (If you  
have an interest in running other OSes on VT-x hardware, you're free  
to try the patch, but I can't say that I'll spend much time trying to  
solve the problems you bump into.)

I believe that the current handling of segment registers in vmxassist  
isn't quite right.  A more complicated model needs to be developed.   
I'm not sure exactly how different it needs to be or exactly in what  
ways it needs to be modified.

But, if this topic interests you, I'd be interested in continuing  
this discussion.

Once you apply the patch, you'll need to perform a make in the xen/ 
tools/firmware directory.  That will cause a new hvmloader to be  
constructed.  You can either install it (I don't recommend it) or you  
can modify your configuration file(s) so that the "kernel" is this  
new hvmloader file:

kernel = "/usr/src/xen-3.0-testing/tools/firmware/hvmloader/hvmloader"

If you've read this far, you might take interest in rereading my post  
on this problem:

http://lists.xensource.com/archives/html/xen-devel/2006-05/msg01300.html

-- Randy Thelen

[-- Attachment #2: v86-segment.patch --]
[-- Type: application/octet-stream, Size: 1044 bytes --]

diff -r edefe24d78bd tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c	Tue Apr 11 12:51:48 2006 +0100
+++ b/tools/firmware/vmxassist/vm86.c	Tue May 30 23:17:06 2006 -0700
@@ -749,8 +749,22 @@ load_seg(unsigned long sel, uint32_t *ba
 		return 0;
 
 	if (sel == 0) {
-		arbytes->fields.null_bit = 1;
-		return 1;
+		/*
+		 * Create an entry with the following properties:
+		 * base = 0, limit = 1MB
+		 * Present, DPL = 0, granularity = 4KB
+		 * seg type = data, grow up, writable, not accessed.
+		 * 32 bit code in the segment.
+		 * This segment may not be an ideal segment descriptor
+		 * but I selected it (from FreeBSD, in fact) because
+		 * with a selector in 16 bit mode with a value of 0,
+		 * that means that the 1MB starting at address 0 is
+		 * available to the code.  This simply tries to
+		 * immitate that behavior.
+		 */
+		entry = 0x00cf92000000ffffULL;
+	} else {
+		entry =  ((unsigned long long *) oldctx.gdtr_base)[sel >> 3];
 	}
 
 	entry =  ((unsigned long long *) oldctx.gdtr_base)[sel >> 3];

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: VMX Assist and x86 segment registers

[Petersson, Mats]

Randy, 

There are several places in Xen where the weirdness of using protected
mode segments in real mode or the other way around break things. I can't
comment on the validity of your fix as such - but here's a few comments
on the COMMENT of the segment data:

Since you've set the granularity bit to 1 -> 4KB "steps" in limit (the
top bit of c in 00cf92), I think you'll find that the first 4GB of RAM
is accessible, since you've also set the upper bits of the twenty-bit
segment limit (the F in the snippet of segment data above), the segment
limit being 0xfffff << 12 + 0xfff -> 0xffffffff == 0-(4GB-1). 

Also, it's not a code-segment (or you've have the top bit in the nibble
that is  now 2 in the cf92 bits), but a data-segment, so you have 32-bit
DATA in the segment, not 32-bit code

You may as well set the accessed bit - no one cares about it, but it
saves a write to the segment descriptor when it becomes accessed the
first time... It used to be important in 16-bit segmented mode, where
segments could be swapped out (before paging became available - this is
what the Present bit is for, and of course, if you have a segment that
hasn't been accessed for a while, that would be a good candidate for
chucking out to disk, if other segments need to be brought into RAM...
OS/2 1.x would have used this for "virtual" memory support...)

You can't tell that I've struggled with segments just a few times
before, can you? ;-)

--
Mats



> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Randy Thelen
> Sent: 31 May 2006 07:42
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] VMX Assist and x86 segment registers
> 
> Executive summary --
> 
> If you're interested in running FreeBSD in an HVM domain on 
> VT-x hardware, please EXPERIMENT with the attached patch.  
> However, the patch is not in and of itself a fix.  I'm simply 
> looking for more help on solving this bigger problem and 
> pushing the patch to the Xen community is the best way I 
> could think of to get more insight into the problem.
> 
> If you're still interested, please continue reading.
> 
> Folks --
> 
> Here's an esoteric topic: x86 segment registers and their 
> emulation with vmxassist.  Anybody interested in engaging in 
> this one? ;-)
> 
> Here's the story.  FreeBSD doesn't boot on Intel processors 
> with VT-x hardware in an HVM domain.  It turns out I'm 
> dependent upon that functionality.  So, I began to 
> investigate.  Dragons lie in them thar hills.  (Snakes, 
> spiders, whatever: I -hate- segmentation and I -
> hate- segment registers.  So you can imagine the frustration 
> I had as I realized I needed to become intimately familiar 
> with them to solve my problem.)
> 
> Here's the deal, the x86 processor allows segment registers 
> to be set in one mode (e.g., "real mode") and the used in 
> another mode (e.g., "protected mode").  For an example of how 
> this trick is utilized, peruse subject 15:  Accessing 4 Gigs 
> of Memory in Real Mode:
> 
> http://www.cs.uu.nl/wais/html/na-dir/assembly-language/x86/general/
> part2.html
> 
> (Be prepared to be completely disgusted.)
> 
> At any rate, between my own debugging and reading articles of 
> the sort above, I realized that vmxassist was incorrectly 
> handling segment registers.
> 
> I've made a patch that I've attached but I am -NOT- 
> recommending this for general consumption.  This patch is 
> -ONLY- recommended for those who want to run FreeBSD on VT-x 
> hardware and those who are willing to work through additional 
> bugs to solve interesting problems.  (If you have an interest 
> in running other OSes on VT-x hardware, you're free to try 
> the patch, but I can't say that I'll spend much time trying 
> to solve the problems you bump into.)
> 
> I believe that the current handling of segment registers in 
> vmxassist  
> isn't quite right.  A more complicated model needs to be developed.   
> I'm not sure exactly how different it needs to be or exactly 
> in what ways it needs to be modified.
> 
> But, if this topic interests you, I'd be interested in 
> continuing this discussion.
> 
> Once you apply the patch, you'll need to perform a make in 
> the xen/ tools/firmware directory.  That will cause a new 
> hvmloader to be constructed.  You can either install it (I 
> don't recommend it) or you can modify your configuration 
> file(s) so that the "kernel" is this new hvmloader file:
> 
> kernel = "/usr/src/xen-3.0-testing/tools/firmware/hvmloader/hvmloader"
> 
> If you've read this far, you might take interest in rereading 
> my post on this problem:
> 
> http://lists.xensource.com/archives/html/xen-devel/2006-05/msg
> 01300.html
> 
> -- Randy Thelen
> 

Re: VMX Assist and x86 segment registers

[Anthony Liguori]

Big real mode is definitely a problem in vm86 mode.  FreeBSD is also 
notorious for its use of segmentation :-)  I think it has been proposed 
that a potential solution is to do away with vmxassist entirely and 
instead use qemu to emulate 16 bit mode (or another emulator if 
available).  Not sure if anyone is actually working on that yet though.  
It seems to be the most promising solution.

Regards,

Anthony Liguori

Randy Thelen wrote:
> Executive summary --
>
> If you're interested in running FreeBSD in an HVM domain on VT-x 
> hardware, please EXPERIMENT with the attached patch.  However, the 
> patch is not in and of itself a fix.  I'm simply looking for more help 
> on solving this bigger problem and pushing the patch to the Xen 
> community is the best way I could think of to get more insight into 
> the problem.
>
> If you're still interested, please continue reading.
>
> Folks --
>
> Here's an esoteric topic: x86 segment registers and their emulation 
> with vmxassist.  Anybody interested in engaging in this one? ;-)
>
> Here's the story.  FreeBSD doesn't boot on Intel processors with VT-x 
> hardware in an HVM domain.  It turns out I'm dependent upon that 
> functionality.  So, I began to investigate.  Dragons lie in them thar 
> hills.  (Snakes, spiders, whatever: I -hate- segmentation and I -hate- 
> segment registers.  So you can imagine the frustration I had as I 
> realized I needed to become intimately familiar with them to solve my 
> problem.)
>
> Here's the deal, the x86 processor allows segment registers to be set 
> in one mode (e.g., "real mode") and the used in another mode (e.g., 
> "protected mode").  For an example of how this trick is utilized, 
> peruse subject 15:  Accessing 4 Gigs of Memory in Real Mode:
>
> http://www.cs.uu.nl/wais/html/na-dir/assembly-language/x86/general/part2.html 
>
>
> (Be prepared to be completely disgusted.)
>
> At any rate, between my own debugging and reading articles of the sort 
> above, I realized that vmxassist was incorrectly handling segment 
> registers.
>
> I've made a patch that I've attached but I am -NOT- recommending this 
> for general consumption.  This patch is -ONLY- recommended for those 
> who want to run FreeBSD on VT-x hardware and those who are willing to 
> work through additional bugs to solve interesting problems.  (If you 
> have an interest in running other OSes on VT-x hardware, you're free 
> to try the patch, but I can't say that I'll spend much time trying to 
> solve the problems you bump into.)
>
> I believe that the current handling of segment registers in vmxassist 
> isn't quite right.  A more complicated model needs to be developed.  
> I'm not sure exactly how different it needs to be or exactly in what 
> ways it needs to be modified.
>
> But, if this topic interests you, I'd be interested in continuing this 
> discussion.
>
> Once you apply the patch, you'll need to perform a make in the 
> xen/tools/firmware directory.  That will cause a new hvmloader to be 
> constructed.  You can either install it (I don't recommend it) or you 
> can modify your configuration file(s) so that the "kernel" is this new 
> hvmloader file:
>
> kernel = "/usr/src/xen-3.0-testing/tools/firmware/hvmloader/hvmloader"
>
> If you've read this far, you might take interest in rereading my post 
> on this problem:
>
> http://lists.xensource.com/archives/html/xen-devel/2006-05/msg01300.html
>
> -- Randy Thelen
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

Re: VMX Assist and x86 segment registers

[Khoa Huynh]

aliguori@us.ltcfwd.linux.ibm.com wrote on 05/31/2006 10:07:08 AM:

> Big real mode is definitely a problem in vm86 mode.  FreeBSD is also
> notorious for its use of segmentation :-)  I think it has been proposed
> that a potential solution is to do away with vmxassist entirely and
> instead use qemu to emulate 16 bit mode (or another emulator if
> available).  Not sure if anyone is actually working on that yet though.
> It seems to be the most promising solution.

Yes, we are thinking of putting a full instruction emulator into
qemu-dm and emulating 16-bit stuff in qemu-dm instead of using
vmxassist (vmxassist will go away).  Leendert van Doorn and I are
working on this.  Thanks.

Regards,
Khoa

Re: VMX Assist and x86 segment registers

[Randy Thelen]

Khoa Huynh wrote:

> Yes, we are thinking of putting a full instruction emulator into
> qemu-dm and emulating 16-bit stuff in qemu-dm instead of using
> vmxassist (vmxassist will go away).  Leendert van Doorn and I are
> working on this.  Thanks.

The problem, as I see it, is the hand-off of the "hidden" or  
"invisible" segmentation register information during the transition  
from emulator to the real hardware and vice-versa.  So, regardless of  
whether qemu-dm is emulating the 16 bit code or vmxassist, the  
correct segment information has to be conveyed for correct execution.

The example of big real mode that I included in my mail was simply to  
note the fact that segment data is persistent across mode changes and  
vmxassist does not carry that information forward to protected mode  
or backward to real mode.

The example code snippet which is relevant here is:

---------bits: 16---------filename: btx.o---------origin:  
00009010---------
00009010 (01) fa                       CLI
00009011 (02) 31c0                     XOR AX, AX
00009013 (02) 8ed0                     MOV SS, AX
00009015 (03) bc 0018                  MOV SP, 0x1800
00009018 (02) 8ec0                     MOV ES, AX
0000901a (02) 8ed8                     MOV DS, AX

At this point DS is zero'd.

00009070 (03) 0f20c0                   MOV EAX, CR0
00009073 (04) 66 83c8 01               OR EAX, 0x1
00009077 (03) 0f22c0                   MOV CR0, EAX
0000907a (05) ea 7f00 0800             JMP FAR 0x8:0x7f

The far jump gets us to 32 bit mode:

---------bits: 32---------filename: btx.o---------origin:  
0000907f---------
0000907f (02) 31c9                     XOR ECX, ECX
00009081 (02) b1 10                    MOV CL, 0x10
00009083 (02) 8ed1                     MOV SS, CX
00009085 (02) b1 38                    MOV CL, 0x38
00009087 (03) 0f00d9                   LTR CX
...
000090ac (06) ff35 0c000000            PUSH DWORD [0xc]

At the point of 90ac, the DS segment is 0.  vmxassist was setting the  
'hidden' fields of the segment register such that ds was being  
interpreted as a null segment.  But it's not null, it's valid.  Qemu- 
dm will need to address this code snippet, too.

-- Randy

RE: VMX Assist and x86 segment registers

[Petersson, Mats]

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Randy Thelen
> Sent: 31 May 2006 18:08
> To: xen-devel
> Subject: Re: [Xen-devel] VMX Assist and x86 segment registers
> 
> Khoa Huynh wrote:
> 
> > Yes, we are thinking of putting a full instruction emulator into 
> > qemu-dm and emulating 16-bit stuff in qemu-dm instead of using 
> > vmxassist (vmxassist will go away).  Leendert van Doorn and I are 
> > working on this.  Thanks.
> 
> The problem, as I see it, is the hand-off of the "hidden" or 
> "invisible" segmentation register information during the 
> transition from emulator to the real hardware and vice-versa. 
>  So, regardless of whether qemu-dm is emulating the 16 bit 
> code or vmxassist, the correct segment information has to be 
> conveyed for correct execution.
> 
> The example of big real mode that I included in my mail was 
> simply to note the fact that segment data is persistent 
> across mode changes and vmxassist does not carry that 
> information forward to protected mode or backward to real mode.
> 
> The example code snippet which is relevant here is:
> 
> ---------bits: 16---------filename: btx.o---------origin:  
> 00009010---------
> 00009010 (01) fa                       CLI
> 00009011 (02) 31c0                     XOR AX, AX
> 00009013 (02) 8ed0                     MOV SS, AX
> 00009015 (03) bc 0018                  MOV SP, 0x1800
> 00009018 (02) 8ec0                     MOV ES, AX
> 0000901a (02) 8ed8                     MOV DS, AX
> 
> At this point DS is zero'd.
> 
> 00009070 (03) 0f20c0                   MOV EAX, CR0
> 00009073 (04) 66 83c8 01               OR EAX, 0x1
> 00009077 (03) 0f22c0                   MOV CR0, EAX
> 0000907a (05) ea 7f00 0800             JMP FAR 0x8:0x7f
> 
> The far jump gets us to 32 bit mode:
> 
> ---------bits: 32---------filename: btx.o---------origin:  
> 0000907f---------
> 0000907f (02) 31c9                     XOR ECX, ECX
> 00009081 (02) b1 10                    MOV CL, 0x10
> 00009083 (02) 8ed1                     MOV SS, CX
> 00009085 (02) b1 38                    MOV CL, 0x38
> 00009087 (03) 0f00d9                   LTR CX
> ...
> 000090ac (06) ff35 0c000000            PUSH DWORD [0xc]
> 
> At the point of 90ac, the DS segment is 0.  vmxassist was 
> setting the 'hidden' fields of the segment register such that 
> ds was being interpreted as a null segment.  But it's not 
> null, it's valid.  Qemu- dm will need to address this code 
> snippet, too.

Whilst what I'm working on at the moment isn't going to solve this
particular problem, it should help getting the information in to/out of
QEMU, as I'm working on putting the x86_emulate.c that is currently used
for parts of instruction emulation in Xen, into QEMU. The next step of
that process would be to add proper support for segment registers
(today, x86_emulate.c doesn't cope well with segments that doesn't have
a base-address of zero, which causes certain OS's to crash - I think
some BSD-version, and I know Minix does this). 

--
Mats
> 
> -- Randy
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 

Re: VMX Assist and x86 segment registers

[Anthony Liguori]

Randy Thelen wrote:
> Khoa Huynh wrote:
>
>> Yes, we are thinking of putting a full instruction emulator into
>> qemu-dm and emulating 16-bit stuff in qemu-dm instead of using
>> vmxassist (vmxassist will go away).  Leendert van Doorn and I are
>> working on this.  Thanks.
>
> The problem, as I see it, is the hand-off of the "hidden" or 
> "invisible" segmentation register information during the transition 
> from emulator to the real hardware and vice-versa.  So, regardless of 
> whether qemu-dm is emulating the 16 bit code or vmxassist, the correct 
> segment information has to be conveyed for correct execution.

vmxassist is the source of the problem here though as it uses vm86 mode 
which means that there is no way to get at the hidden cpu state.  If we 
moved to a model where all 16-bit code was emulated by qemu, we would 
have access to all the hidden cpu state.

There are fewer problems in 32 bit mode since the segmentation stuff is 
mostly visible so there shouldn't be a problem in handing off from the 
16 bit emulator to to direct 32 bit execution.

Regards,

Anthony Liguori

>
> The example of big real mode that I included in my mail was simply to 
> note the fact that segment data is persistent across mode changes and 
> vmxassist does not carry that information forward to protected mode or 
> backward to real mode.
>
> The example code snippet which is relevant here is:
>
> ---------bits: 16---------filename: btx.o---------origin: 
> 00009010---------
> 00009010 (01) fa                       CLI
> 00009011 (02) 31c0                     XOR AX, AX
> 00009013 (02) 8ed0                     MOV SS, AX
> 00009015 (03) bc 0018                  MOV SP, 0x1800
> 00009018 (02) 8ec0                     MOV ES, AX
> 0000901a (02) 8ed8                     MOV DS, AX
>
> At this point DS is zero'd.
>
> 00009070 (03) 0f20c0                   MOV EAX, CR0
> 00009073 (04) 66 83c8 01               OR EAX, 0x1
> 00009077 (03) 0f22c0                   MOV CR0, EAX
> 0000907a (05) ea 7f00 0800             JMP FAR 0x8:0x7f
>
> The far jump gets us to 32 bit mode:
>
> ---------bits: 32---------filename: btx.o---------origin: 
> 0000907f---------
> 0000907f (02) 31c9                     XOR ECX, ECX
> 00009081 (02) b1 10                    MOV CL, 0x10
> 00009083 (02) 8ed1                     MOV SS, CX
> 00009085 (02) b1 38                    MOV CL, 0x38
> 00009087 (03) 0f00d9                   LTR CX
> ...
> 000090ac (06) ff35 0c000000            PUSH DWORD [0xc]
>
> At the point of 90ac, the DS segment is 0.  vmxassist was setting the 
> 'hidden' fields of the segment register such that ds was being 
> interpreted as a null segment.  But it's not null, it's valid.  
> Qemu-dm will need to address this code snippet, too.
>
> -- Randy
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: VMX Assist and x86 segment registers

[Randy Thelen]

Anthony Liguori wrote:

> vmxassist is the source of the problem here though as it uses vm86  
> mode which means that there is no way to get at the hidden cpu  
> state.  If we moved to a model where all 16-bit code was emulated  
> by qemu, we would have access to all the hidden cpu state.
>
> There are fewer problems in 32 bit mode since the segmentation  
> stuff is mostly visible so there shouldn't be a problem in handing  
> off from the 16 bit emulator to to direct 32 bit execution.

I completely agree.  If there's anything I can do to help, e.g.,  
running code in during development, please let me know.

-- Randy

RE: VMX Assist and x86 segment registers

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Anthony Liguori
> Sent: 31 May 2006 20:31
> To: Randy Thelen
> Cc: xen-devel
> Subject: Re: [Xen-devel] VMX Assist and x86 segment registers
> 
> Randy Thelen wrote:
> > Khoa Huynh wrote:
> >
> >> Yes, we are thinking of putting a full instruction emulator into 
> >> qemu-dm and emulating 16-bit stuff in qemu-dm instead of using 
> >> vmxassist (vmxassist will go away).  Leendert van Doorn and I are 
> >> working on this.  Thanks.
> >
> > The problem, as I see it, is the hand-off of the "hidden" or 
> > "invisible" segmentation register information during the transition 
> > from emulator to the real hardware and vice-versa.  So, 
> regardless of 
> > whether qemu-dm is emulating the 16 bit code or vmxassist, 
> the correct 
> > segment information has to be conveyed for correct execution.
> 
> vmxassist is the source of the problem here though as it uses 
> vm86 mode which means that there is no way to get at the 
> hidden cpu state.  If we moved to a model where all 16-bit 
> code was emulated by qemu, we would have access to all the 
> hidden cpu state.
> 
> There are fewer problems in 32 bit mode since the 
> segmentation stuff is mostly visible so there shouldn't be a 
> problem in handing off from the
> 16 bit emulator to to direct 32 bit execution.

Yes, that's correct - except that most of the code in Xen that handles
instruction emulation (for example handling MMIO to QEMU and the
Page-table-write code) assumes that if the processor is in protected
mode, the register base is zero. This works for most parts in Linux and
Windows [nearly always in both those OS's are the base address zero -
and unless the programmer jumps through hoops, it would be for cases
where we need to emulate instructions]. However, there are some other
OS's that actually DO USE segmentation to prevent memory blocks from
leaking into each other, etc. Not to mention that there are plenty of
boot-loaders, BIOS interface-code [for OS's that support legacy devices
by calling to the BIOS instead of writing a dedicated driver,
particularly during boot/installation] and such that do have
"interesting" code in them, either using real-mode segments in protected
mode, or "big real-mode", i.e. setting up a segment that is base=0,
limit=4GB in prot.mode and then using it in real-mode. 

For AMD it's a little bit easier, since we support "paged real-mode", so
we don't need to mess about with VM86 and supporting strange things like
this. 

But for all architectures, the code that currently emulates MMIO
instructions is broken with regards to big real-mode and protected mode
where base != 0. 

--
Mats 


> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > The example of big real mode that I included in my mail was 
> simply to 
> > note the fact that segment data is persistent across mode 
> changes and 
> > vmxassist does not carry that information forward to 
> protected mode or 
> > backward to real mode.
> >
> > The example code snippet which is relevant here is:
> >
> > ---------bits: 16---------filename: btx.o---------origin: 
> > 00009010---------
> > 00009010 (01) fa                       CLI
> > 00009011 (02) 31c0                     XOR AX, AX
> > 00009013 (02) 8ed0                     MOV SS, AX
> > 00009015 (03) bc 0018                  MOV SP, 0x1800
> > 00009018 (02) 8ec0                     MOV ES, AX
> > 0000901a (02) 8ed8                     MOV DS, AX
> >
> > At this point DS is zero'd.
> >
> > 00009070 (03) 0f20c0                   MOV EAX, CR0
> > 00009073 (04) 66 83c8 01               OR EAX, 0x1
> > 00009077 (03) 0f22c0                   MOV CR0, EAX
> > 0000907a (05) ea 7f00 0800             JMP FAR 0x8:0x7f
> >
> > The far jump gets us to 32 bit mode:
> >
> > ---------bits: 32---------filename: btx.o---------origin: 
> > 0000907f---------
> > 0000907f (02) 31c9                     XOR ECX, ECX
> > 00009081 (02) b1 10                    MOV CL, 0x10
> > 00009083 (02) 8ed1                     MOV SS, CX
> > 00009085 (02) b1 38                    MOV CL, 0x38
> > 00009087 (03) 0f00d9                   LTR CX
> > ...
> > 000090ac (06) ff35 0c000000            PUSH DWORD [0xc]
> >
> > At the point of 90ac, the DS segment is 0.  vmxassist was 
> setting the 
> > 'hidden' fields of the segment register such that ds was being 
> > interpreted as a null segment.  But it's not null, it's valid.
> > Qemu-dm will need to address this code snippet, too.
> >
> > -- Randy
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 

Re: VMX Assist and x86 segment registers

[Anthony Liguori]

Petersson, Mats wrote:
>  
>
>   
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
>> Anthony Liguori
>> Sent: 31 May 2006 20:31
>> To: Randy Thelen
>> Cc: xen-devel
>> Subject: Re: [Xen-devel] VMX Assist and x86 segment registers
>>
>> Randy Thelen wrote:
>>     
>>> Khoa Huynh wrote:
>>>
>>>       
>>>> Yes, we are thinking of putting a full instruction emulator into 
>>>> qemu-dm and emulating 16-bit stuff in qemu-dm instead of using 
>>>> vmxassist (vmxassist will go away).  Leendert van Doorn and I are 
>>>> working on this.  Thanks.
>>>>         
>>> The problem, as I see it, is the hand-off of the "hidden" or 
>>> "invisible" segmentation register information during the transition 
>>> from emulator to the real hardware and vice-versa.  So, 
>>>       
>> regardless of 
>>     
>>> whether qemu-dm is emulating the 16 bit code or vmxassist, 
>>>       
>> the correct 
>>     
>>> segment information has to be conveyed for correct execution.
>>>       
>> vmxassist is the source of the problem here though as it uses 
>> vm86 mode which means that there is no way to get at the 
>> hidden cpu state.  If we moved to a model where all 16-bit 
>> code was emulated by qemu, we would have access to all the 
>> hidden cpu state.
>>
>> There are fewer problems in 32 bit mode since the 
>> segmentation stuff is mostly visible so there shouldn't be a 
>> problem in handing off from the
>> 16 bit emulator to to direct 32 bit execution.
>>     
>
> Yes, that's correct - except that most of the code in Xen that handles
> instruction emulation (for example handling MMIO to QEMU and the
> Page-table-write code) assumes that if the processor is in protected
> mode, the register base is zero. This works for most parts in Linux and
> Windows [nearly always in both those OS's are the base address zero -
> and unless the programmer jumps through hoops, it would be for cases
> where we need to emulate instructions]. However, there are some other
> OS's that actually DO USE segmentation to prevent memory blocks from
> leaking into each other, etc. Not to mention that there are plenty of
> boot-loaders, BIOS interface-code [for OS's that support legacy devices
> by calling to the BIOS instead of writing a dedicated driver,
> particularly during boot/installation] and such that do have
> "interesting" code in them, either using real-mode segments in protected
> mode, or "big real-mode", i.e. setting up a segment that is base=0,
> limit=4GB in prot.mode and then using it in real-mode. 
>
> For AMD it's a little bit easier, since we support "paged real-mode", so
> we don't need to mess about with VM86 and supporting strange things like
> this. 
>
> But for all architectures, the code that currently emulates MMIO
> instructions is broken with regards to big real-mode and protected mode
> where base != 0. 
>   

Even QEMU doesn't fully implement proper segmentation semantics.  For 
instance, it doesn't enforce segment limits IIRC.

We should be careful when we do get around to making the switch over and 
make sure we don't enable code to do things it shouldn't do.

Regards,

Anthony Liguori

> --
> Mats 
>
>
>   
>> Regards,
>>
>> Anthony Liguori
>>
>>     
>>> The example of big real mode that I included in my mail was 
>>>       
>> simply to 
>>     
>>> note the fact that segment data is persistent across mode 
>>>       
>> changes and 
>>     
>>> vmxassist does not carry that information forward to 
>>>       
>> protected mode or 
>>     
>>> backward to real mode.
>>>
>>> The example code snippet which is relevant here is:
>>>
>>> ---------bits: 16---------filename: btx.o---------origin: 
>>> 00009010---------
>>> 00009010 (01) fa                       CLI
>>> 00009011 (02) 31c0                     XOR AX, AX
>>> 00009013 (02) 8ed0                     MOV SS, AX
>>> 00009015 (03) bc 0018                  MOV SP, 0x1800
>>> 00009018 (02) 8ec0                     MOV ES, AX
>>> 0000901a (02) 8ed8                     MOV DS, AX
>>>
>>> At this point DS is zero'd.
>>>
>>> 00009070 (03) 0f20c0                   MOV EAX, CR0
>>> 00009073 (04) 66 83c8 01               OR EAX, 0x1
>>> 00009077 (03) 0f22c0                   MOV CR0, EAX
>>> 0000907a (05) ea 7f00 0800             JMP FAR 0x8:0x7f
>>>
>>> The far jump gets us to 32 bit mode:
>>>
>>> ---------bits: 32---------filename: btx.o---------origin: 
>>> 0000907f---------
>>> 0000907f (02) 31c9                     XOR ECX, ECX
>>> 00009081 (02) b1 10                    MOV CL, 0x10
>>> 00009083 (02) 8ed1                     MOV SS, CX
>>> 00009085 (02) b1 38                    MOV CL, 0x38
>>> 00009087 (03) 0f00d9                   LTR CX
>>> ...
>>> 000090ac (06) ff35 0c000000            PUSH DWORD [0xc]
>>>
>>> At the point of 90ac, the DS segment is 0.  vmxassist was 
>>>       
>> setting the 
>>     
>>> 'hidden' fields of the segment register such that ds was being 
>>> interpreted as a null segment.  But it's not null, it's valid.
>>> Qemu-dm will need to address this code snippet, too.
>>>
>>> -- Randy
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>       
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>>     
>
>   

RE: VMX Assist and x86 segment registers

[Kamble, Nitin A]

Khoa,
  Before vmxassist we were using Gunnison emulator inside Intel to do
the real mode emulation. We still have that code around. 
  I would like to know what is your time line for completing the qemu-dm
task?

Thanks & Regards,
Nitin
------------------------------------------------------------------------
-----------
Open Source Technology Center, Intel Corp

>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>bounces@lists.xensource.com] On Behalf Of Khoa Huynh
>Sent: Wednesday, May 31, 2006 9:20 AM
>To: aliguori@us.ibm.com
>Cc: Randy Thelen; xen-devel@lists.xensource.com; xen-devel-
>bounces@lists.xensource.com
>Subject: Re: [Xen-devel] VMX Assist and x86 segment registers
>
>
>
>aliguori@us.ltcfwd.linux.ibm.com wrote on 05/31/2006 10:07:08 AM:
>
>> Big real mode is definitely a problem in vm86 mode.  FreeBSD is also
>> notorious for its use of segmentation :-)  I think it has been
proposed
>> that a potential solution is to do away with vmxassist entirely and
>> instead use qemu to emulate 16 bit mode (or another emulator if
>> available).  Not sure if anyone is actually working on that yet
though.
>> It seems to be the most promising solution.
>
>Yes, we are thinking of putting a full instruction emulator into
>qemu-dm and emulating 16-bit stuff in qemu-dm instead of using
>vmxassist (vmxassist will go away).  Leendert van Doorn and I are
>working on this.  Thanks.
>
>Regards,
>Khoa
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel

RE: VMX Assist and x86 segment registers

[Leendert Van Doorn]

That should be a matter of weeks after we've done the switch over to
qemu-0.8.1.

      Leendert

------------------------
Dr. Leendert van Doorn
Senior Manager - Secure Systems and Tools
IBM T.J. Watson Research Center




                                                                           
             "Kamble, Nitin A"                                             
             <nitin.a.kamble@i                                             
             ntel.com>                                                  To 
                                       Khoa Huynh/Austin/IBM@IBMUS,        
             06/01/2006 10:02          aliguori@us.ltcfwd.linux.ibm.com,   
             PM                        Leendert Van Doorn/Watson/IBM@IBMUS 
                                                                        cc 
                                       <xen-devel@lists.xensource.com>,    
                                       "Yu, Wilfred"                       
                                       <wilfred.yu@intel.com>, "Nakajima,  
                                       Jun" <jun.nakajima@intel.com>,      
                                       "Mallick, Asit K"                   
                                       <asit.k.mallick@intel.com>          
                                                                   Subject 
                                       RE: [Xen-devel] VMX Assist and x86  
                                       segment registers                   
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Khoa,
  Before vmxassist we were using Gunnison emulator inside Intel to do
the real mode emulation. We still have that code around.
  I would like to know what is your time line for completing the qemu-dm
task?

Thanks & Regards,
Nitin
------------------------------------------------------------------------
-----------
Open Source Technology Center, Intel Corp

>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>bounces@lists.xensource.com] On Behalf Of Khoa Huynh
>Sent: Wednesday, May 31, 2006 9:20 AM
>To: aliguori@us.ibm.com
>Cc: Randy Thelen; xen-devel@lists.xensource.com; xen-devel-
>bounces@lists.xensource.com
>Subject: Re: [Xen-devel] VMX Assist and x86 segment registers
>
>
>
>aliguori@us.ltcfwd.linux.ibm.com wrote on 05/31/2006 10:07:08 AM:
>
>> Big real mode is definitely a problem in vm86 mode.  FreeBSD is also
>> notorious for its use of segmentation :-)  I think it has been
proposed
>> that a potential solution is to do away with vmxassist entirely and
>> instead use qemu to emulate 16 bit mode (or another emulator if
>> available).  Not sure if anyone is actually working on that yet
though.
>> It seems to be the most promising solution.
>
>Yes, we are thinking of putting a full instruction emulator into
>qemu-dm and emulating 16-bit stuff in qemu-dm instead of using
>vmxassist (vmxassist will go away).  Leendert van Doorn and I are
>working on this.  Thanks.
>
>Regards,
>Khoa
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel