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

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

On Thu, 2015-03-26 at 12:24 +0100, Tamas K Lengyel wrote:

> >>  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.
> 
> IMHO it's very minor performance tuning and for data access violations
> the cache probably already has the same translation so I wouldn't be
> surprised if the two would cost the same amount of cycles. For
> prefetch it's useful because we don't have to rely on the cache being
> valid.

I'm thinking along the lines of:
        if (HPFAR_EL2 is valid)
                ipa = read HPFAR_EL2
        else
                ipa = gva_to_ipa of FAR_EL2 (via info.gva)

Then handle ipa as usual, including potentially an ipa->pa/pte lookup
when needed, which is safe because we guarantee that we don't play TLB
tricks to try and game ourselves.

The bit I've not yet convinced myself of is whether "HPFAR_EL2 is valid"
is true for all the potentially problematic cases. TFM says (G4.13.5):

        For any Access flag fault or Translation fault, and also for any
        Permission fault on the stage 2 translation of a memory access
        made as part of a translation table walk for a stage 1
        translation, the
        HPFAR holds the IPA that caused the fault. Otherwise, the HPFAR
        is UNKNOWN .

So that excludes Address Size and Access flag, but I think we don't care
about those, or at least not in a way which would require us to do a
lookup.

Table G4-33 also looks very informative too BTW.

Anyway, that all sounds pretty promising, we'd need to do a bit more
deciding of the FSC than we do today but that's not too hard.

>  Furthermore, I yet to see a single event being delivered that
> happened during s1ptw. For some reason my domain's normal operations
> don't seem to trigger any, even if I create new processes etc..

You would need to make a stage 1 page table entry be non-present or at
least not readable to hit that, I suppose you have tried doing so via
xenaccess e.g. setting all of guest to some suitable type? Very strange
not to then see a s1ptw fault.

The other way would be xenpaging, which we don't do on ARM.

Ian.