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

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Thu, Dec 04, 2014 at 01:49:47PM +0000, 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.
> 
> 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?

Yes.

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

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