> From: Baolu Lu <baolu...@linux.intel.com> > Sent: Sunday, July 3, 2022 12:34 PM > > On 2022/7/1 15:58, Tian, Kevin wrote: > >> From: Lu Baolu <baolu...@linux.intel.com> Sent: Wednesday, June 29, > >> 2022 3:47 PM > >> > >> The disable_dmar_iommu() is called when IOMMU initialization fails > >> or the IOMMU is hot-removed from the system. In both cases, there > >> is no need to clear the IOMMU translation data structures for > >> devices. > >> > >> On the initialization path, the device probing only happens after > >> the IOMMU is initialized successfully, hence there're no > >> translation data structures. > >> > >> On the hot-remove path, there is no real use case where the IOMMU > >> is hot-removed, but the devices that it manages are still alive in > >> the system. The translation data structures were torn down during > >> device release, hence there's no need to repeat it in IOMMU > >> hot-remove path either. This removes the unnecessary code and only > >> leaves a check. > >> > >> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> > > > > You probably overlooked my last comment on kexec: > > > > > https://lore.kernel.org/lkml/BL1PR11MB52711A71AD9F11B7AE42694C8CAC9 > @BL1PR11MB5271.namprd11.prod.outlook.com/ > > > > I think my question is still not answered. > > Sorry! I did overlook that comment. I can see your points now, though it > seems to be irrelevant to the problems that this series tries to solve. > > The failure path of copying table still needs some improvement. At least > the pages allocated for root/context tables should be freed in the > failure path. Even worse, the software occupied a bit of page table > entry which is feasible for the old ECS, but not work for the new > scalable mode anymore. > > All these problems deserve a separate series. We could address your > concerns there. Does this work for you?
Yes, this makes sense to me. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
