On Tue, Oct 17, 2023 at 08:52:49AM +0000, Tian, Kevin wrote: > > This is why I wanted to get rid of this bad mechanism going forward. > > > > Manually created hwpt should have a manual specification of cc and > > then we don't have so many problems. > > > > It means userspace needs to compute if they want to use CC or not, but > > userspace already needs to figure this out since without autodomains > > it must create two hwpts manually anyhow. > > > > Now there is no interface reporting enforce_cc to userspace. Yes.. > Actually the user doesn't need to know enforce_cc. As long as there is > an attach incompatibility error the user has to create a 2nd hwpt for > the to-be-attached device then enforce_cc will be handled automatically > in hwpt_alloc. Uh, OK we can do that.. It is a bit hacky because we don't know the order do > I prefer to removing enforce_cc in attach fn completely then no parent > trick in this patch. Just keep it in hwpt_alloc and leave to iommu driver to > figure out the attaching compatibility: You are basically saying to set the cc mode during creation because we know the idev at that moment and can tell if it should be on/off? It seems reasonable, but I can't remember why it is in the attach path at the moment. Jason
