Xen project Mailing List

On Mon, Mar 23, 2015 at 5:47 PM, Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx> wrote:

On Mon, Mar 23, 2015 at 5:22 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> On Mon, 2015-03-23 at 16:47 +0100, Tamas K Lengyel wrote:
>>
>>
>> On Mon, Mar 23, 2015 at 4:18 PM, Ian Campbell
>> <ian.campbell@xxxxxxxxxx> wrote:
>>Â Â Â Â ÂOn Mon, 2015-03-23 at 15:15 +0000, Ian Campbell wrote:
>>Â Â Â Â Â> _But_ I suppose you are not really worried about the guest
>>Â Â Â Â Âdoing a PT
>>Â Â Â Â Â> update, but rather xenaccess playing games with the stage 2
>>Â Â Â Â Âbehind the
>>Â Â Â Â Â> guest's back, which might require us to do some TLB
>>Â Â Â Â Âshootdowns, and we'd
>>Â Â Â Â Â> have to assume both I-TLB and D-TLB since we don't know what
>>Â Â Â Â Âthe guest
>>Â Â Â Â Â> has in those pages.
>>
>>Â Â Â Â ÂWhen we change the p2m we do a tlbi vmalle1is, so regardless
>>Â Â Â Â Âof whether
>>Â Â Â Â Âsplit tlb is a thing we are flushing everything, so we should
>>Â Â Â Â Âbe good
>>Â Â Â Â Âfrom a stage 2 PoV.
>>
>>
>> When we apply p2m changes we do indeed flush the TLB. I do actually
>> worry about a potential malicious in-guest kernel playing tricks with
>> its pagetables which may have happened after the p2m changes were
>> applied. The xen-access permissions are applied based on IPAs. Say I
>> want to be notified when a specific API is being called, so I walk the
>> guest-pagestables and set a trap at the page the IPA is one. If the
>> malicious guest kernel wants to avoid triggering the xen-access
>> notifications, it could theoretically prime its tables and perform the
>> right accesses so that the iTLB still has the mapping I wanted to trap
>> with xen-access, but the dTLB has a different mapping. The instruction
>> abort trap will happen but in Xen I will see the mapping according to
>> the dTLB, thus the radix-tree lookup fails and the trap is injected
>> back into the guest.
>
> But in that case the guest will take a trap, so what has it gained other
> than a spurious trap?

Bypassing the notification being sent to the subscriber application
about the trap.

>
> I can't see anything in the TLB chapter of the ARMv8 ARM which suggests
> split TLBs are possible in AArch64 mode, and the AArch32 refs look like
> backwards compat stuff to me.
>
> The ARMv7 ARM does mention the split, but only to say that the
> distinction between the ITLB and DTLB maintenance operations is
> deprecated and that modern TLB ops do not support the distinction. It's
> not 100% unambiguous about whether split TLBs themselves are allowed in
> ARMv7 though, and in particular I'm not sure what impact the addition of
> the LPAE and virtualisation extensions will have had on these
> requirements. I also can't quite tell if split TLB is allowed on VMSA
> systems, or if it is PMSA only.
>
> As you might imagine I'm not keen on adding TLB flushes "just in case",
> so I would really like to see some good references to the architecture
> specs before adding a flush on this path.
>
> Ian.

IMHO a TLB flush in this path is low impact for systems that don't use
xen-access. As far as which hardware supports it, I see the following
for A53 (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500f/BIIJFHJD.html):

10-entry fully-associative instruction micro TLB.
10-entry fully-associative data micro TLB.

For A57 (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500f/BIIJFHJD.html):

48-entry fully-associative L1 instruction TLB.
32-entry fully-associative L1 data TLB for data load and store pipelines.

Tamas

Ian,

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.

It's unfortunate we can't make the MMU get us the translation as if doing a prefetch, only as a data access. It's also unfortunate that during a Permission fault we don't get the IPA associated with the fault, only the GVA. 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.

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..

Tamas

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