From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Xen-4.5 HVMOP ABI issues Date: Thu, 4 Dec 2014 16:45:32 +0000 Message-ID: <54808FAC.6070308@citrix.com> References: <54785E46.4080107@citrix.com> <5478819F020000780004B70D@mail.emea.novell.com> <54787ED8.2010508@citrix.com> <5478A056020000780004B7CE@mail.emea.novell.com> <547898E7.30400@citrix.com> <5480748B020000780004CBFC@mail.emea.novell.com> <54806FA2.6080406@citrix.com> <548083EE020000780004CC90@mail.emea.novell.com> <548081D6.4080208@citrix.com> <548095C4020000780004CD59@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <548095C4020000780004CD59@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Tim Deegan , IanCampbell , Xen-develList List-Id: xen-devel@lists.xenproject.org On 04/12/14 16:11, Jan Beulich wrote: >>>> On 04.12.14 at 16:46, wrote: >> On 04/12/14 14:55, Jan Beulich wrote: >>>>>> On 04.12.14 at 15:28, wrote: >>>> On 04/12/14 13:49, Jan Beulich wrote: >>>>>>>> On 28.11.14 at 16:46, wrote: >>>>>> On 28/11/14 15:18, Jan Beulich wrote: >>>>>>>>>> On 28.11.14 at 14:55, 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