From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH V14 5/7] xen/arm: Instruction prefetch abort (X) mem_access event handling Date: Fri, 27 Mar 2015 12:21:21 +0000 Message-ID: <55154B41.2090807@linaro.org> References: <1427407531-31694-1-git-send-email-tklengyel@sec.in.tum.de> <1427407531-31694-6-git-send-email-tklengyel@sec.in.tum.de> <55149473.1010108@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel Cc: "wei.liu2@citrix.com" , Ian Campbell , Stefano Stabellini , Tim Deegan , Ian Jackson , Xen-devel , Stefano Stabellini , Jan Beulich , Keir Fraser List-Id: xen-devel@lists.xenproject.org Hi Tamas, On 27/03/15 08:32, Tamas K Lengyel wrote: > + /* > + * Flush the TLB to make sure the DTLB is clear before > + * doing GVA->IPA translation. If we got here because of > + * an entry only present in the ITLB, this translation may > + * still be inaccurate. > + */ > + flush_tlb_domain(current->__domain); > > > flush TLB domain is very expensive, it flushes TLBs on every CPU. > While you may only need a flush on the current CPU. > > > Ack, there just isn't a function at the moment to do tlbflush only for a > given cpu. There is one function to flush the TLB only on the current CPU. See flush_tlb_local. flush_tlb_domain is an helper in order to flush TLB on another domain than the current one. > While I understand the argument behind the performance > impact of the flush, any user of the mem_access system would IMHO prefer > accuracy over performance. As I said before, this path seldom ever > triggers without mem_access triggering it. Without memaccess, we always inject a prefetch abort with the virtual address. So we don't care about the flush TLB here. > > > Although, on ARMv8, there is no possibility to flush only DTLB or > ITLB for aarch64. You have to do both at the same time. So the > problem you are describing can't happen. After reading the > ID_MMFR2_EL1, I understand that Unified TLB is strongly advice on > ARMv8 so any DTLB/ITLB flush would flush the unified TLB for aarch32 > guest. > > > The problem I'm describing doesn't depend on having separate DTLB/ITLB > flush operations available, albeit those making life a lot for a > potential malicious in-guest kernel. There were no separate flush > operations on x86 either and split-TLB poisoning was still a thing. The > introduction of the sTLB is what made it less usable for malicious purposes. What I was trying to say is given ID_MMFR2_EL1, I think ARMv8 only support unified TLB. But I might be wrong... Regards, -- Julien Grall