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
Petersson, Mats
2006-May-31 09:02 UTC
RE: [Xen-devel] VMX Assist and x86 segment registers
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori
2006-May-31 15:07 UTC
Re: [Xen-devel] VMX Assist and x86 segment registers
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-May-31 17:16 UTC
RE: [Xen-devel] VMX Assist and x86 segment registers
> -----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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori
2006-May-31 19:31 UTC
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. 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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-Jun-01 09:33 UTC
RE: [Xen-devel] VMX Assist and x86 segment registers
> -----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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori
2006-Jun-01 20:48 UTC
Re: [Xen-devel] VMX Assist and x86 segment registers
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 >> >> >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kamble, Nitin A
2006-Jun-02 02:02 UTC
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 beenproposed>> 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 yetthough.>> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Leendert Van Doorn
2006-Jun-02 15:30 UTC
RE: [Xen-devel] VMX Assist and x86 segment registers
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel