Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Apr 12, 2016 at 09:17:29AM -0600, Jan Beulich wrote:
> >>> George Dunlap <dunlapg@umich.edu> 04/12/16 11:58 AM >>>
> >On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>> ISTM that the lower duplication (which in principle is an advantage
> >>> which will be time limited if we are ever able to completely remove
> >>> teh old hypercall) comes with the cost of (in the long term) increased
> >>> mess in this particular subop.
> >>
> >> We cannot, ever, remove a not toolstack limited hypercall completely
> >> (or if, then only by Kconfig option so that people knowing none of the
> >> guests they care about use such deprecated ones).
> >
> >We need to keep the hypercall around and functioning for ABI
> >compatibility, but we could at least remove it from the public headers
> >and point people to using the new one instead.  (Discussion about the
> >merit of this idea below.)
> 
> Please don't forget that guests use this to be deprecated hypercall as one of the
> cheapest possible ways to call into the hypervisor just to get events delivered.
> I'm afraid the new hypercall would mean (slightly) more overhead. In fact I'm
> afraid the addition of the XSM call to the old one already had some of this effect
> namely when XSM is enabled: Konrad - was this considered when you added
> that?

Yes, and I raised it up as well :-)

However, now that we dropped the XSM checks for some of the sub-ops,
it is pointless to do the XSM checks for them (they just do
function functions calls that end up with return 0).

I can most certainly add back the mask of flags - so only specific sub-ops
go through the XSM check. Let me write a patch for this and send it
out for review shortly.
> 
> >OK, so here are the options I see:
> >
> >1. Use the existing hypercall with the existing call semantics for
> >build-id -- i.e., require the caller to have a large but fixed-length
> >buffer (maybe 1024 or 2048).
> 
> I think it was explained even on this thread that a fixed size may indeed not
> be suitable here.
> 
> >2. Use the existing hypercall but wedge in different calling semantics
> >for the build-id subop.  We could have just that subop pay attention
> >to an extra argument as a length, for example, and return an error if
> >the length is too short.  Or we could make essentially a flag that
> >asks, "How much space if I were to execute this subop for real?"
> 
> A suitable variant of this is what I've been arguing for.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel