Baolu: Sorry that my last reply email seems not text format. Resend it now.
Thanks for your comments and your patch. Please find below our responses to each of your comments: > What does "I/O operation won't work" exactly mean here? Do you see any > IOMMU fault message? Or, something doesn't work as expected? Yes, DMAR fault messages as following came out: [ 354.939896] DMAR: DMAR:[DMA Read] Request device [03:00.1]fault addr 1fdfe80000 [ 354.939896] DMAR:[fault reason 02] Present bit in context entry is clear > Do you mind checking this? > > index 6ecdcf8fc8c0..f62f30bc1339 100644 > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -2632,6 +2632,9 @@ static struct dmar_domain > *find_or_alloc_domain(struct device *dev, int gaw) > goto out; > } > > + if (!iommu_should_identity_map(dev, 0)) > + return si_domain; > + > /* Allocate and initialize new domain for the device */ > domain = alloc_domain(0); > if (!domain) Tried this patch, and the same DMAR fault message came out. Guess it is because of the iommu code path for hotplug devices. If a hotplug device is rescanned after removal, iommu_bus_notifier will be called as part of the notifier chains to handle BUS_NOTIFY_ADD_DEVICE event. Along the code path, intel_iommu_ops->add_device() created an iommu group for this hotplug device, but failed to create an iommu domain because of the default domain type IOMMU_DOMAIN_IDENTITY imposed by current IOMMU command line option got declined by intel_iommu_ops->domain_alloc(). Since si_domain is type of "struct dmar_domain", which is platform dependent, it is hard to make this change in intel_iommu_ops->domain_alloc(). In your patch, function find_or_alloc_domain() is not in the code path of BUS_NOTIFY_ADD_DEVICE event notifier chain. Please let us know if your have more concerns and suggestions. Best Regards, James _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
