Re: [Xen-devel] hypercall_xlat_continuation()

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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