[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.