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).
I don't think so. If a CPU in real mode is allowed to use
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
I don't really understand the implications of not supporting
segment bases in real mode guests (what code actually does
but since it can't work in the current implementation, this patch
not be breaking it ...
this not break "big real-mode" type behaviour? Or am I missing
here? Certainly the x86 architecture itself allows the segment
mode) to have a different base address than the "selector <<
that you get when you LOAD a selector in REAL MODE. It's just that
real-mode, you can't set a different base, but code that has
run in non-real mode (i.e. enter protected mode then set
register than exit back to real-mode) can do all sorts of magic.
is really expected behaviour, it would also be expected to have a
of 0xffff, or you're sort of half-breaking the rules
Xen-devel mailing list