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()

To: Jan Beulich <JBeulich@xxxxxxxxxx>, "mukesh.rathor@xxxxxxxxxx" <mukesh.rathor@xxxxxxxxxx>
Subject: Re: [Xen-devel] hypercall_xlat_continuation()
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 27 May 2009 09:58:36 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 27 May 2009 01:59:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A1D14550200007800002C9D@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcnepEcgCdZSbgiSQQGeKya2Ji6GGgABQqt1
Thread-topic: [Xen-devel] hypercall_xlat_continuation()
User-agent: Microsoft-Entourage/12.17.0.090302
On 27/05/2009 09:22, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> Because it's conceptually wrong.

Nothing conceptually wrong with it at all. Just another hypervisor service
being made available to a higher level of software.

> 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.

We add a compat32 wrapping hypercall, and shift the actual hypercall number
to a different register. Noone takes a hit but the 32-bit userspace which
has already bounced via ring 1 and this will not add an extra measurable
overhead.

> 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).

Firstly, I don't see us bringing in extensive build-time configuration any
time soon. Secondly, if someone wanted this new compat32-for-userspace
support, they would simply have to install a new hypervisor configured with
compat32 support -- how is that harder/worse than installing a new kernel
configured with compat32 support?

At the end of the day, the thought of *duplicating* the compat32 stuff and
then trying to stuff it upstream to kernel.org does not appeal. I see that
as two major concrete negatives versus the much weaker negatives on the
other side of the argument.

 -- Keir



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