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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Consequently what I'd like to propose (and I guess I'll craft a patch
as soon as I finished this mail) is that we add comments to these
masks (also the memop one) to make clear that they mustn't change.
Additionally for forward compatibility I'd also like to add checks for
the upper bits to be zero for any of the sub-ops that don't actually
use them to encode continuation information. Konrad, would you
consider doing so acceptable for 4.5?

Jan


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