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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Hypercalls from HVM guests

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Hypercalls from HVM guests
From: Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx>
Date: Sat, 22 Apr 2006 11:16:48 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 22 Apr 2006 08:17:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <15277a6e2bde8c0d0a88162b1d5eee55@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <444920C7.2070705@xxxxxxxxxxxxxxx> <15277a6e2bde8c0d0a88162b1d5eee55@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050715)
Keir Fraser wrote:

On 21 Apr 2006, at 19:13, Steve Ofsthun wrote:

With these changes you can make raw hypercalls from HVM guests.

You probably want a separate hypercall table from that of paravirtualized guests, for several reasons: 1. Some hypercalls will not be HVM aware and are probably unsafe to run from an HVM context

Which hypercalls in particular should be excluded from HVM use?

A number will require changes to perform properly for HVM guests.  This work
will require this patch.  In particular, follow on patches for grant table
operations, event channel operations, and memory operations all require this
initial groundwork.

Are you concerned that enabling this patch will make the hypervisor more
vulnerable in some way?

Shouldn't the hypervisor interface be made robust enough to deal with HVM
guests (as well as malfunctioning paravirtualized guests)?

If it is just a matter of testing, I could filter all HVM requests for now
and only allow requests through that have been exercised.  As additional
patches are submitted, we could enable new hypercalls to be passed through
the HVM interface.

2. Some hypercalls may want different implementations (or at least a wrapper) on HVM

If this becomes necessary, it can be added to the interface.

3. On 64-bit, you may even want a separate 32-bit hypercall table containing wrappers that interface between 32-bit callers and the core 64-bit hypercall functions.

At the moment, all of this can be dealt with in HVM DomU code.  By doing it
there, we can avoid explicit parameter copying on every hypercall.  The 32-bit
vs. 64-bit hypercall interface variations are not unique to HVM code.  Adding
conversion interfaces in the hypervisor is only one solution to this problem.
The interfaces themselves could be made size invariant.  Except for backward
compatibility, the 32-bit interfaces could be made identical to the 64-bit
interfaces using proper data typing and explicit data alignment.

(1) is most important right now -- we should only permit the hypercalls we need, and audit any others before they are added to the list.

OK, is a bitmap filter of the inbound requests sufficient?  For this patch, I'll
just filter every hypercall except HYPERVISOR_xen_version() and return ENOSYS?

Steve Ofsthun - Virtual Iron Software, Inc.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>