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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

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@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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel