[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
>>> On 04.11.15 at 18:06, <Ian.Jackson@xxxxxxxxxxxxx> wrote: > Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro > set_xen_guest_handle_raw"): >> On 04.11.15 at 17:50, <Ian.Jackson@xxxxxxxxxxxxx> wrote: >> > If we don't provide a get_xen_guest_handle, a kernel developer will be >> > sorely tempted to make one. >> >> What use would it be to them? Kernels only write handles, they >> shouldn't have a need for reading them. > > I foresee situations where a kernel might like to update a proposed > hypercall argument structure in place, which might involve reading the > handles. I guess you think of e.g. the privcmd filtering done in XenServer, but I think this is an odd thing for a kernel to do: Down to the final actual hypercall invocation, it should deal with pointers, not handles. Filtering should either be done prior to reaching that layer (obviously not an option for privcmd, but that layer is guarded against issues with the compiler doing the wrong thing afaict), or would better be left to the hypervisor (said filtering in XenServer could likely be moved into the hypervisor, with a flag added to the hypercall number indicating whether to invoke the filtering, which the privcmd layer then would set unconditionally). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |