Re: [Xen-devel] Questioning the Xen Design of the VMM

[Steven Rostedt <srostedt@xxxxxxxxxx>]

Mats, thanks for the examples of where the hypervisor needs to know 
otherwise x86 guest doesn't do what it expects to be done.
I've just recently started working with Xen, but my background has been 
more with other architectures than x86.  I understand all that you 
explained, but one: see below. (I'm posting to the list so that others 
can learn too ;)
Petersson, Mats wrote:
>  
[ snipped a lot of good info ]

> Another problem is "hidden bits" in registers. 
>
> Let's say this:
>
>         mov     cr0, eax
>         mov     eax, ecx
>         or      $1, eax
>         mov     eax, cr0
>         mov     $0x10, eax
>         mov     eax, fs
>         mov     ecx, cr0
>         
>         mov     $0xF000000, eax
>         mov     $10000, ecx
> $1:
>         mov     $0, fs:eax
>         add     $4, eax
>         dec     ecx
>         jnz     $1
>
> Let's now say that we have an interrupt that the hypervisor would handle
> in the loop in the above code. The hypervisor itself uses FS for some
> special purpose, and thus needs to save/restore the FS register. When it
> returns, the system will crash (GP fault) because the FS register limit
> is 0xFFFF (64KB) and eax is greater than the limit - but the limit of FS
> was set to 0xFFFFFFFF before we took the interrupt... Incorrect
> behaviour like this is terribly difficult to deal with, and there really
> isn't any good way to solve these issues [other than not allowing the
> code to run when it does "funny" things like this - or to perform the
> necessary code in "translation mode" - i.e. emulate each instruction ->
> slow(ish)]. 
The above I'm confused on.  In x86, the hypervisor can't store the fs 
register fully before returning from the interrupt??  You stated that 
the fs register limit was 0xffffffff before the interrupt, but ends up 
being 0xffff afterwards.  As I mentioned, I'm just learning the 
internals of x86, so my full comprehension on segment registers of x86 
is still a little fuzzy.
Could you explain further here?

Thanks,

-- Steve


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