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: Hypercall number assignment convension (was Re: [Xen-devel] Re:[PATC

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: Hypercall number assignment convension (was Re: [Xen-devel] Re:[PATCH]: kexec: framework and i386)
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 26 Apr 2006 08:55:50 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx>, Horms <horms@xxxxxxxxxxxx>, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Delivery-date: Wed, 26 Apr 2006 01:00:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E7B9A@pdsmsx403>
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: <571ACEFD467F7749BC50E0A98C17CDD8094E7B9A@pdsmsx403>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 26 Apr 2006, at 08:54, Tian, Kevin wrote:

Then we may need to fill that breathing space with do_ni_hypercall
to ensure no leakage from NR_hypercall check. If that's the case,
how about define the __HYPERVISOR_arch_* at end of 256 spaces,
and fill all unused entries with do_ni_hypercall. By that way, the check to illegal hypercall (<256) is a bit slower, however it shouldn't matter
for that rare cases.

Yes, it would need filling with ni_hypercall: we already do that on x86 anyway (since hypercall table is rounded up to a power of two).

I don't want to put the hypercalls that far up: with one hypercall page x86 will currently have a problem implementing more than 128 hypercalls. I also don't want to put them right at the end of the hypercall space because that would make it harder/uglier to add extra arch hypercalls later on.

I think 48-55 would be reasonable.

 -- Keir

Xen-devel mailing list