Re: Xen-4.5 HVMOP ABI issues

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 04/12/14 16:11, Jan Beulich wrote:
>>>> On 04.12.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>> On 04/12/14 14:55, Jan Beulich wrote:
>>>>>> On 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
>>>> On 04/12/14 13:49, Jan Beulich wrote:
>>>>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>>>>> On 28/11/14 15:18, Jan Beulich wrote:
>>>>>>>>>> On 28.11.14 at 14:55, <andrew.cooper3@citrix.com> wrote:
>>>>>>>> The problem is with continuations which reuse the upper bits of the
>>>>>>>> input register, not with this HVMOP_op_mask specifically; the
>>>>>>>> HVMOP_op_mask simply adds to an existing problem.  This is something
>>>>>>>> which needs considering urgently because, as you identify above, we have
>>>>>>>> already suffered an accidental ABI breakage with the mem-op widening.
>>>>>>> Since we can't retroactively fix the mem-op widening, I still don't see
>>>>>>> what's urgent here: As long as we don't change any of these masks,
>>>>>>> nothing bad is going to happen. Of course one thing to consider with
>>>>>>> this aspect in mind is whether to change the hvm-op or gnttab-op
>>>>>>> masks again _before_ 4.5 goes out, based on whether we feel they're
>>>>>>> wide enough for the (un)foreseeable future.
>>>>>> By urgent, I mean exactly this, while we have the ability to tweak the
>>>>>> masks.
>>>>> With no-one else voicing an opinion:
>>>>>
>>>>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>>>>
>>>>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>>>>
>>>>> For the latter, we're fine even without further consideration. For the
>>>>> former, the two operations actively using the continuation encoding
>>>>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>>>>> and since it was intended for the tools-only HVM-ops to be split off
>>>>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>>>>> would then no longer be a problem. Plus, in the worst case we could
>>>>> always introduce yet another hypercall if we ran out of numbers.
>>>> Are you suggesting that we make a new hvmctl now and remove the hvmop
>>>> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
>>>> subsequently remove it even if all continuable hypercalls move to a
>>>> separate hypercall.
>>> Why? We certainly don't guarantee compatibility for undefined
>>> hypercalls to behave in a certain way.
>> A task is in the middle of a hypercall continuation.  The VM is migrated
>> to a newer Xen which has lost the op mask and gained a new hypercall
>> which would alias.
> Impossible: A continuation could be in progress only when we
> actually use the high bits (or else you have nowhere to encode
> it). Operations not using continuations consequently aren't
> susceptible to the mask disappearing.

Ah yes - if nothing guest usable is currently continuable, then this is ok.

~Andrew