On 25 May 2018 at 10:50, Auger Eric <eric.au...@redhat.com> wrote: > On 05/25/2018 10:52 AM, Peter Maydell wrote: >> Once we've flushed the TLB it is empty and will have no cached >> information from the IOMMU. So there's no point in flushing the >> TLB again (which is expensive) until the next time a transaction >> goes through the IOMMU and we're caching something from it. > Ak OK. there is no finer granularity for TLB flush?
Yes, there is -- you can flush by (input) address; but I opted to do a global flush, because it doesn't require complicated tracking of which parts of the IOMMU's address range we care about, and in general I expect IOMMU config changes to be fairly rare: + /* Rather than trying to register interest in the specific part + * of the iommu's address space that we've accessed and then + * expand it later as subsequent accesses touch more of it, we + * just register interest in the whole thing, on the assumption + * that iommu reconfiguration will be rare. + */ We can always come back and revisit that if there turns out to be a performance problem here in practice. >> We need to know all the permissions (because we'll cache the result >> in the TCG TLB and later use them for future read and write accesses), >> so we pass IOMMU_NONE. >> >> My understanding from previous discussion is that the only >> reason to pass in some other access flag value is if you >> only care about one of read or write and want to allow the >> IOMMU to stop walking the page table early as soon as it decides >> it doesn't have permissions. > > agreed. So you need to fetch the whole set of table permissions to > update the TLB. By the way where is the TLB updated? tlb_set_page_with_attrs() calls address_space_translate_for_iotlb(), which looks up what's at that address, including doing IOMMU translations. Then tlb_set_page_with_attrs() fills in the TLB data structure with the results. thanks -- PMM
