>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 21.08.06 12:52 >>>
>On 21/8/06 11:19 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> While originally I expected to get at least the fundamentals of this done
>> without need to change the ABI in any form, I quickly ran into issues with
>> the GDT layout (since the guest usable selectors are published I consider
>> them part of the ABI): Obviously, the selector values used to run a 32bit
>> guest should match those of the 32bit hv, and hence the GDT layout
>> needs to be changed for the 64bit hv. This is despite context switches
>> between 32bit and 64bit guests needing to switch the GDT, since
>> __HYPERVISOR_DS32 overlaps 32bit's FLAT_RING1_CS32. The GDT
>> switching itself will be necessary because the 32bit guest must not be
>> able to use FLAT_RING3_CS64.
>
>This doesn't sound like a showstopper to me. We just move __HYPERVISOR_DS32
It's not a showstopper - I didn't mean to sound like that.
>to a different location on x86/64 (it's not part of the ABI). Then we
That won't work I think - syscall needs __HYPERVISOR_CS64 and
__HYPERVISOR_DS32 to be adjacent. I'm rather moving
__HYPERVISOR_CS32 out of the way right now, and move the other
two up by one entry.
>context switch entries 3,4,5,6 of the GDT. In fact entry 3 can perhaps stay
>as ring-1 code, and we only need to switch entries 4,5,6.
Hmm, that would mean per-CPU GDTs. I'm right now creating a second GDT,
and map into the guest's page tables the appropriate one. On a context
switch, the most that should be needed on top of what's done today then is
to flush the one page from the TLB (I didn't check that, but I suppose it's
a global translation).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home