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
|
Home