Re: [PATCH V13 5/7] xen/arm: Instruction prefetch abort (X) mem_event handling

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-03-24 at 14:06 +0100, Tamas K Lengyel wrote:

> according to the ARM ARM v8 split TLB is possible, see section TLB
> matching (page 1826): "In some cases, the TLB can hold two mappings
> for the same address". In fact, it seems like some hardware can even
> detect such cases and cause a Data-abort or Prefetch abort with error
> code TLB Conflict (see section TLB conflict aborts, page 1827). They
> did indeed deprecate the separate maintenance operations but that
> doesn't really effect the problem I'm describing. 

(FWIW this is page 1754 in revision DDI0487A.d of the doc)

I'm not sure that the "In some cases" wording is talking about split
TLBs, but rather a potential occurrence with in a single TLB when
invalidation is not properly performed. If there were 2 TLBs I would
expect them to operate independently, so there would be no possibility
of a conflict.

> It's unfortunate we can't make the MMU get us the translation as if
> doing a prefetch, only as a data access.

Part of me thinks that if split TLBs were possible then an instruction
to do this would have been provided...

I'm going to ask around and see if I can find a definitive answer on
this.

>  It's also unfortunate that during a Permission fault we don't get the
> IPA associated with the fault, only the GVA.

FWIW I think this is because an allowable implementation is to only
cache the final PA+perms result of Stage 1+2 rather than caching the two
stages separately (which is also allowed), so it's possible that the h/w
wouldn't have the IPA in its hand.

>  I looked at the KVM code and they seem to query HPFAR_EL2 if the
> fault is during s1ptw, but otherwise they do exactly what we do here.

Yes, reading their comment there lead me to the bit of the ARM ARM and I
think there may be improvements we could make to the non-xenaccess case
at least, I was confused about HPFAR_EL2 va FAR_EL2 earlier.

> So, IMHO doing a TLB flush here would prevent a primed DTLB becoming a
> problem. Not sure if that helps if the ITLB is primed however as we
> would have no way to replicate the translation that is cached..

Ian.