WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] hypercall_xlat_continuation()

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 27.05.09 10:04 >>>
>On 27/05/2009 09:02, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>>>> You know that all the 'xlat' stuff in Xen is for 32-bit guests running on
>>>> 64-bit hypervisor, right? 64-bit dom0 would never execute this logic.
>>> 
>>> Unless someone like me, in trying to make 32bit apps on 64bit dom0 work,
>>> causes it to take compat path if it's 32bit hcall. Yeah, I know whacky :)...
>> 
>> I don't think that's a good approach - even when dealing with 32-bit apps,
>> it's a 64-bit kernel, and hence you should rather translate things to the
>> 64-bit format in the kernel layer that sits in between (after all, apps can't
>> do hypercalls directly).
>
>Why would you do that when the tedious translation mechanism already exists
>in the hypervisor?

Because it's conceptually wrong. And the necessary extra de-muxing that's
needed (because the int $HYPERCALL_VECTOR path can't be used) is not
going to come without a (performance) price.

A secondary reason is that as soon as Xen becomes more easily build-time
configurable (like Linux is), which I expect to happen at some point (unless
we manage to replace all those build time decisions with runtime ones), a
64-bit guest can't really rely on the hypervisor having compat mode support
(and considering backward compatibility, which might not matter in the
context the subject was brought up in, such an assumption would be wrong
in the first place).

Jan


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