This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] VMX Assist and x86 segment registers

To: "Randy Thelen" <rthelen@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] VMX Assist and x86 segment registers
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Wed, 31 May 2006 11:02:42 +0200
Delivery-date: Wed, 31 May 2006 02:21:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <73055A70-2CEB-4E3A-AD17-252DF3F2666B@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaEfd5S3v2hyistTq2NYNDW6pQeeQAELcLQ
Thread-topic: [Xen-devel] VMX Assist and x86 segment registers

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? ;-)


> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Randy Thelen
> Sent: 31 May 2006 07:42
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> 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