Xen devel - Feb 2008 - sysenter/syscall support for 32-on-64 guests?

I just spent quite a while working out why pvops-Xen kernels weren''t 
booting for me in a 64-bit hypervisor.  It turned out to be because 
32-on-64 supports SEP even though 32-on-32 doesn''t, so the guest kernel
was trying to use it without having set up the Xen side, resulting in 
syscalls jumping to 0:0, generating a mysterious GP.  Once I worked that 
out, the fix was simple, of course.

Anyway, I wonder if you had a specific reason for allowing this, other 
than "because we can"?  It seems to me that we should try to minimize 
the number of differences between 32-on-32 and 32-on-64 as much as possible.

    J

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

>>> Jeremy Fitzhardinge <jeremy@goop.org> 28.02.08 17:49
>>>
>I just spent quite a while working out why pvops-Xen kernels
weren''t
>booting for me in a 64-bit hypervisor.  It turned out to be because 
>32-on-64 supports SEP even though 32-on-32 doesn''t, so the guest
kernel
>was trying to use it without having set up the Xen side, resulting in 
>syscalls jumping to 0:0, generating a mysterious GP.  Once I worked that 
>out, the fix was simple, of course.
>
>Anyway, I wonder if you had a specific reason for allowing this, other 
>than "because we can"?  It seems to me that we should try to
minimize
>the number of differences between 32-on-32 and 32-on-64 as much as possible.
Since int80 cannot be directly passed to the guest (as in 32-on-32), it
seemed reasonable to cut on the overhead of syscalls by at least
allowing this (and syscall could also be made work now that the vdso
stuff is unified in 2.6.25) - for obvious reasons it still goes through the
hypervisor, but gets there faster

Jan


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

Jan Beulich wrote:
> Since int80 cannot be directly passed to the guest (as in 32-on-32), it
> seemed reasonable to cut on the overhead of syscalls by at least
> allowing this (and syscall could also be made work now that the vdso
> stuff is unified in 2.6.25) - for obvious reasons it still goes through the
> hypervisor, but gets there faster
>   
I guess that''s a reasonable point.  But it does mean that
you''d need to
separately validate a 32-bit guest on both a 32 and 64-bit hypervisor, 
which is a bit painful.  Maybe you''d need to do that anyway... (Or 
ignore 32-bit hosts.)

    J

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

On 28/2/08 17:14, "Jan Beulich" <jbeulich@novell.com> wrote:
>> Anyway, I wonder if you had a specific reason for allowing this, other
>> than "because we can"?  It seems to me that we should try to
minimize
>> the number of differences between 32-on-32 and 32-on-64 as much as
possible.
> 
> Since int80 cannot be directly passed to the guest (as in 32-on-32), it
> seemed reasonable to cut on the overhead of syscalls by at least
> allowing this (and syscall could also be made work now that the vdso
> stuff is unified in 2.6.25) - for obvious reasons it still goes through the
> hypervisor, but gets there faster
Ah yes, I must admit I temporarily forgot you can only target 64-bit code
segments in a long-mode IDT.

 -- Keir



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