[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry
On 01/08/2016 19:22, Mark Rutland wrote: Hi, Hi Mark, I realised I made a confusing mistake in my last reply; clarification below. On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote:On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote:however we only need one TLBI instruction (assuming there is no superpage shattering) per-batch rather than one per-entry in this case.I got Cc'd to a reply without the original patch context, so I'm not sure what the case is here. I'm not exactly sure what you mean by "per-batch". Sorry for that. I CCed in case I did not summarize correctly the conversation we had. The page table handling code can be found in patch #18 [1]. Assuming that you've (only) changed the permissions (i.e. the AP bits and XN bits) of a number of stage-2 leaf entries, you need either:[...]* Per entry, a TLBI IPAS2LE1IS e.g. for_each_entry(x) modify_ap_bits(x); dsb(ishst); tlbi(ipas2le1is); dsb(ish);Here I was trying to have the bare minimum barriers necessary, but in focussing on that I failed to add the required loop to have a TLBI per entry. The above should have been: for_each_entry(x) modify_ap_bits(x); dsb(ishst); for_each_entry(x) tlbi(ipas2le1is, x); dsb(ish); I have a question related to this example. Is there a threshold where invalidate all the TLB entry for a given VMID/ASID is worth? Assuming the necessary bit fiddling for the TLBI to affect the IPA of x, with the right VMID, etc. Regards, [1] https://lists.xen.org/archives/html/xen-devel/2016-07/msg02966.html -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |