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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: Hypercall number assignment convension (was Re: [Xen-devel] Re:[PATCH]: kexec: framework and i386)
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 26 Apr 2006 15:54:05 +0800
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 00:54:44 -0700
Envelope-to: www-data@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/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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZpBP0DntZ/dy+9Rz2I/Cf+frEvmwAAEU9g
Thread-topic: Hypercall number assignment convension (was Re: [Xen-devel] Re:[PATCH]: kexec: framework and i386)
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2006年4月26日 15:38
>
>On 26 Apr 2006, at 03:34, Tian, Kevin wrote:
>
>> I prefer to the first one. However not the current
>> __HYPERVISOR_arch_specific_0, *_1, *_2, ..., how about just call
>> it as __HYPERVISOR_arch_specific_ops which contains another
>> namespace defined by different architecture seperately?
>
>Sometimes you might want a fast hypercall that doesn't have two levels
>of demultiplexing, or where the register/stack parameters are carefully
>crafted and would not fit with an ioctl()-style hypercall (see x86's
>IRET hypercall).

See.

>
>How about reserving 8 or 16 arch-specific hypercalls up front?
>#define __HYPERVISOR_arch_0  32
>  ...
>#define __HYPERVISOR_arch_7  39
>
>We could give a bit of breathing space to the non-arch range by
>starting __HYPERVISOR_arch_* at. e.g., 40 or 48?
>
>  -- Keir

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.

Thanks,
Kevin

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