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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-03-23 at 15:32 +0100, Tamas K Lengyel wrote:

>         +    register_t gva = READ_SYSREG(FAR_EL2);
>         
> 
> 
> So I have a question here. The following call to gva_to_ipa will use
> the MMU to translate the gva as if it was a data-read access. However,
> we got here because of an instruction fetch access. I did a quick
> check and (at least some) ARM CPUs have split-TLBs. So technically
> using gva_to_ipa here could get us an IPA that wasn't the actual
> address if the guest pagetable has since been updated and the TLBs
> primed. Should the TLB be flushed here just to be sure we have an
> accurate translation?

Interesting question, I'd need to spend some time with the ARM ARM to
figure out what is allowable here both in terms of seeing stale entries
or even in whether split TLBs are allowed on modern ARM (i.e. I'm not
sure if split-TLBs are allowed on architectures new enough to have virt
extensions or not).

My initial gut reaction is that if the guest has updated a pagetable but
not flushed the I-TLB then it would be permissible for it to see stale
mappings, even on native. The documented procedure for updating a
mapping of text space involves lots of barriers and flushes etc.

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

So there might well be a missing TLB flush somewhere, but it may not be
in this code...

Ian.



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