RE: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX

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

Leendert was fixing problems caused by this a while back.

 

The essence is that you have some code that want's to generally access real-mode BIOS functions, but also access "high memory", typically when booting [loading the image from disk - once the image is in memory we can switch to protected mode once and for all]  (this is ONE example, there's other things you can do that needs this functionality). There's two solutions to my example:

1. Switch between real-mode and protected mode many times - this is not just performance-wise a bad idea, but it also makes the code have lots of stuff in it that causes problems - for example, do you allow interrupts only when in protected mode, only in real-mode, or do you have TWO sets of interrupt handling and switch that too? [If you rely on the BIOS, you probably need to use REAL MODE for interrupt handling].

2. Do a short visit into protected mode and set some segment register to base = 0, limit = 4G and use that for the duration of this processing. Typically, this is the GS or FS segment, since that segment isn't being used by the BIOS or commonly used in real-mode code. Then you can use a GS prefix together with a 32-bit address override [i.e. mov  %eax, gs:(%ebx) - or whatever the syntax is in gas]. If you tried this in a "traditional" real-mode register, it would GP-fault if the ebx register is bigger than 64K, and combined with the maximum segment base being 0xFFFF, you can only access (1M + 64K - 16) bytes of memory, which may not be good enough to for example load the OS into memory.

 

I know that SLES 9 uses this mode of operation for graphical boot mode - it loads the graphics image from the disk onto the VGA card using "big real mode".

 

What I'm not sure about is whether this gets run only once during boot (in which case it's fine) or every time you switch to/from the domain (in which case it isn't fine).

 

--

Mats

---

From: Dave Lively [mailto:dave.lively@xxxxxxxxx]
Sent: 02 May 2006 17:05
To: Petersson, Mats
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX

I don't think so.  If a CPU in real mode is allowed to use
a segment base set in another mode (to something other than
sel << 4), I think that's outside the scope of what vmxassist
was designed to do.  (Because vmxassist relies on vm86 mode,
and the VMX spec says vm86 mode guests must have their segment
bases = sel << 4 upon vmentry ... and the chips certainly behave
as specified in this regard.)

I don't really understand the implications of not supporting arbitrary
segment bases in real mode guests (what code actually does this?),
but since it can't work in the current implementation, this patch must
not be breaking it ...
 

Dave

Will this not break "big real-mode" type behaviour? Or am I missing
something here? Certainly the x86 architecture itself allows the segment
(in real mode) to have a different base address than the "selector << 4"
that you get when you LOAD a selector in REAL MODE. It's just that in
real-mode, you can't set a different base, but code that has temporarily
run in non-real mode (i.e. enter protected mode then set segment
register than exit back to real-mode) can do all sorts of magic. If this
is really expected behaviour, it would also be expected to have a limit
of 0xffff, or you're sort of half-breaking the rules still...

--
Mats

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