Xen devel - Aug 2006 - 32bit/PAE guest on 64bit hypervisor work

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.

Further, in order to prevent the patch(es) from growing unusably
large, will it be acceptable to submit incremental pieces of this work
without the whole thing working, yet?

Thanks, Jan

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

On 21/8/06 11:19 am, "Jan Beulich" <jbeulich@novell.com> 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
to a different location on x86/64 (it''s not part of the ABI). Then we
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.

And yes: incremental patches are definitely best. There are multiple people
working on this so we want to avoid duplicated effort and also make sure we
all agree the strategy for implementing this feature.

 -- Keir



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

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 21.08.06 12:52
>>>
>On 21/8/06 11:19 am, "Jan Beulich" <jbeulich@novell.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21/8/06 12:04 pm, "Jan Beulich" <jbeulich@novell.com> wrote:
>> 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).
Per-CPU GDTs would be perfectly acceptable (it''s only an extra page per
CPU). But I suppose since we switch pagetables anyway on the ctxt switch
path we may as well just have the appropriate ones mapped in each pagetable,
and remove use of the global bit for that mapping.

 -- Keir



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

>>> 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).
>
>Per-CPU GDTs would be perfectly acceptable (it''s only an extra page
per
>CPU). But I suppose since we switch pagetables anyway on the ctxt switch
>path we may as well just have the appropriate ones mapped in each pagetable,
>and remove use of the global bit for that mapping.
Hmm, why flush the entry on systems where compatibility mode isn''t
used. I''d
rather keep the global flag and make the flush explicit, but conditional upon
old and new vcpu''s domain having different compatibility mode settings.

Jan

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

On 21/8/06 1:11 pm, "Jan Beulich" <jbeulich@novell.com> wrote:
>> Per-CPU GDTs would be perfectly acceptable (it''s only an extra
page per
>> CPU). But I suppose since we switch pagetables anyway on the ctxt
switch
>> path we may as well just have the appropriate ones mapped in each
pagetable,
>> and remove use of the global bit for that mapping.
> 
> Hmm, why flush the entry on systems where compatibility mode isn''t
used. I''d
> rather keep the global flag and make the flush explicit, but conditional
upon
> old and new vcpu''s domain having different compatibility mode
settings.
I suppose we can invlpg that entry.

 -- Keir



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