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

["Jan Beulich" <jbeulich@suse.com>]

>>> 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?

>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