Re: [Xen-devel] Xen-4.5 HVMOP ABI issues

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.12.14 at 16:46, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/12/14 14:55, Jan Beulich wrote:
>>>>> On 04.12.14 at 15:28, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 04/12/14 13:49, Jan Beulich wrote:
>>>>>>> On 28.11.14 at 16:46, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> On 28/11/14 15:18, Jan Beulich wrote:
>>>>>>>>> On 28.11.14 at 14:55, <andrew.cooper3@xxxxxxxxxx> 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.

Jan


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