[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |