On Wed, Dec 11, 2019 at 07:15:44PM +1100, Alexey Kardashevskiy wrote: > > > On 11/12/2019 02:35, Ram Pai wrote: > > On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote: > >> ..snip.. > >> As discussed in slack, by default we do not need to clear the entire TCE > >> table and we only have to map swiotlb buffer using the small window. It > >> is a guest kernel change only. Thanks, > > > > Can you tell me what code you are talking about here. Where is the TCE > > table getting cleared? What code needs to be changed to not clear it? > > > pci_dma_bus_setup_pSeriesLP() > iommu_init_table() > iommu_table_clear() > for () tbl->it_ops->get() > > We do not really need to clear it there, we only need it for VFIO with > IOMMU SPAPR TCE v1 which reuses these tables but there are > iommu_take_ownership/iommu_release_ownership to clear these tables. I'll > send a patch for this.
Did some experiments. It spent the first 9s in tce_free_pSeriesLP() clearing the tce entries. And the second 13s in tce_setrange_multi_pSeriesLP_walk(). BTW: the code in tce_setrange_multi_pSeriesLP_walk() is modified to use DIRECT_TCE. So it looks like the amount of time spent in tce_setrange_multi_pSeriesLP_walk() is a function of the size of the memory that is mapped in the ddw. > ..snip.. > > > But before I close, you have not told me clearly, what is the problem > > with; 'share the page, make the H_PUT_INDIRECT_TCE hcall, unshare the > > page'. > > Between share and unshare you have a (tiny) window of opportunity to > attack the guest. No, I do not know how exactly. > > For example, the hypervisor does a lot of PHB+PCI hotplug-unplug with > 64bit devices - each time this will create a huge window which will > share/unshare the same page. No, I do not know how exactly how this can > be exploited either, we cannot rely of what you or myself know today. My > point is that we should not be sharing pages at all unless we really > really have to, and this does not seem to be the case. > > But since this seems to an acceptable compromise anyway, > > Reviewed-by: Alexey Kardashevskiy <a...@ozlabs.ru> > Thanks! RP
