Re: [Xen-devel] Ping: [PATCH v2 01/11] public / x86: introduce hvmctl hypercall

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 01/07/16 17:18, Jan Beulich wrote:
>>>> On 24.06.16 at 12:28, <JBeulich@xxxxxxxx> wrote:
>> ... as a means to replace all HVMOP_* which a domain can't issue on
>> itself (i.e. intended for use by only the control domain or device
>> model).
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> On the x86 side I'm just lacking feedback for this patch.

I have just spent the afternoon being bitten extremely hard by our
current unstable domctl abi, and in particular, the change of
DOMCTL_API_VERSION when nothing relevant has changed, and am leaning
towards David's views.

With the current definition, we have 32 bits of cmd space, proper
continuation logic via the opaque field, and 120 bytes of per-cmd space
in the union, which plenty.

How about making a proactive start to our ABI stabilisation effort,
dropping the interface_version entirely and declaring this stable?  We
would of course want to triple check the suitability of the existing
ops, but that can easily be rolled into this series (if any action is
needed).


Another area (which is related to the issue which bit me) is the
stability of operations like DOMCTL_pausedomain, which is unlikely to
ever change.

If we do chose to stabilise, we should design the new calls around how
they would be used.  We could do with a stable interface for "general
emulator routines", which applies equally to things like pause/unpause
and ioreq_server*, as opposed to most of the new hvmctl ops, which are
specific to qemu being an LPC bus emulator.

One thing I hadn't considered until now is that this takes an existing
stable ABI and replaces it with an unstable ABI, which is a step
backwards in terms of usability.  There are certainly other advantages
to moving the ops out of hvmop, but the instability is a detracting factor.

~Andrew

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