> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, January 21, 2015 6:31 PM > > > > > Yes, it's true. But I still don't understand why to do the flush_all just > > when > > iommu_enable is true. Could you explain why ? > > The question you raise doesn't reflect what the function does: It > doesn't flush when iommu_enabled, in calls > p2m_memory_type_changed() in that case. And that operation is > what requires a flush afterwards (unless we know that nothing can > be cached yet), as there may have been a cachable -> non- > cachable transition for some of the pages assigned to the guest. > > The fact that the call is made dependent on iommu_enabled is > simply because when that flag is not set, all memory of the > guest is treated WB (as no physical device can be assigned to > the guest in that case), and hence to type changes can occur. > Possibly one could instead use need_iommu(d), but I didn't > properly think through eventual consequences of doing so. >
using need_iommu(d) can minimize the impact to only guests with device assigned. of course just check need_iommu(d) is not enough, since a guest may be hotplugged with a device thus there may be dirty cache lines before need_iommu(d) becoming true. this can be amended by forcing a flush_all in assign_device if noting one or more memory type changes happened before. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
