Re: [Xen-devel] [PATCH 4/4] xen/arm64: Emulate correctly the register {w, x}zr

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-12-15 at 11:41 +0000, Julien Grall wrote:
> Hi Ian,

Thanks for the replies, I think mostly adding the further exposition from
this thread to the commit message would make this patch OK.
> 
> On 15/12/15 11:10, Ian Campbell wrote:
> > On Fri, 2015-12-11 at 15:28 +0000, Julien Grall wrote:
> > > On AArch64, the encoding 31 could be used to represent {x,w}sp or
> > > {x,w}zr (See C1.2.4 in ARM DDI 0486A.d). The choice will depend how
> > > the
> > > register field is interpreted by the instruction.
> > > 
> > > All the instructions trapped by Xen (either via a sysreg access or
> > > data
> > > abort) interprets the encoding 31 as zr. Therefore we don't have to
> > > worry about decoding the instruction.
> > 
> > Is decoding the only way we could tell? i.e. there's no indication in
> > the
> > syndrome reg?
> 
> Unfortunately yes, the syndrome reg will only contain the encoding of
> the transferred register.
> 
> However, by looking to the list of instruction that could be trapped by
> Xen and contain valid ISS, the encoding 31 will always mean zr.

Great.

> > Is there no way a data abort could result from an access which involved
> > SP
> > rather than XZ? e.g. if the OS was to (stupidly) point SP at an MMIO
> > area
> > and then try a stp x0, x1, [sp] for example? Ah, perhaps in that case
> > we
> > would get a trap with x0 or x1 but sp would be in the FAR and not in
> > the
> > HSR?
> 
> First if the instruction stp trap into Xen, the ISS would be invalid.
> 
> For AArch64, only loads and store of a single general-purpose register
> would result to a valid ISS (see D7-1880 in ARM DDI 0487A.d).
> 
> If we take an instruction producing a valid ISS:
> 
> ldr x0, [x2]
> str x0, [x2]
> 
> The ISS will always contains the transfered register, i.e x0 here. The
> faulting address (x2) will be in FAR.

Great. And the SP can only appear as the [sp] slot, so ldr x0 [sp] but
never ldr sp [x0], so that's ok for us too.
>Â
> > Or maybe a less lunatic case, could xenaccess not result in a faulting
> > stack access? I suppose the answer there is that xenaccess faults are
> > handled without actually caring which register it was and then the
> > instruction is replayed in guest context?
> 
> xenaccess can't rely on the instruction syndrome because the fault may
> happen with instruction producing invalid ISS.

Right, this was my theory too.

> > What happens if an aarch32 guest accesses r15 in one of these ways on an
> > aarch64 hypervisor? Is it verboten in ARM v8 or something else? E1.2.3
> > describes it as deprecated, but not forbidden, but I suspect that "and the
> > source address of the ldr is in MMIO space" is not covered there or
> > something.
> 
> Based on the description of the ISS encoding for data abort, the
> syndrome would be invalid.
> 
> Our data abort handler will inject a data abort to the guest for any
> invalid instruction.
> 
> If we ever want to support the guest to write pc in an emulated MMIO, we
> would have to decode the instruction.

I doubt we would want to, but so long as the worst which can happen is that
we kill the guest (rather than the host) then I'm happy.

> > Alternatively we could return NULL here to represent XZR and handle that
> > appropriately in the {get,set}_user_reg, replacing the check for reg == 31 
> > in both places.
> 
> I would rather avoid select_user_regs to return NULL. The explicit
> encoding check in {get,set}_user_reg is better.

OK.

Ian.

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