On Mon, Oct 23, 2023 at 02:53:20AM +0000, Tian, Kevin wrote:
From: Nicolin Chen nicolinc@nvidia.com Sent: Monday, October 23, 2023 8:18 AM
On Sat, Oct 21, 2023 at 01:38:04PM -0300, Jason Gunthorpe wrote:
On Fri, Oct 20, 2023 at 11:59:13AM -0700, Nicolin Chen wrote:
On Fri, Oct 20, 2023 at 10:55:01AM -0300, Jason Gunthorpe wrote:
On Fri, Oct 20, 2023 at 02:43:58AM +0000, Tian, Kevin wrote:
But the user shouldn't assume such explicit consistency since it's not defined in our uAPI. All we defined is that the attaching may fail due to incompatibility for whatever reason then the user can always try creating a new hwpt for the to-be-attached device. From this regard I don't see providing consistency of result is necessary. 😊
Anyhow, OK, lets add a comment summarizing your points and remove
the
cc upgrade at attach time (sorry Nicolin/Yi!)
Ack. I will send a small removal series. I assume it should CC stable tree also?
No, it seems more like tidying that fixing a functional issue, do I misunderstand?
Hmm. Maybe the misunderstanding is mine -- Kevin was asking if it was already a bug and you answered yes: https://lore.kernel.org/linux-iommu/20231016115736.GP3952@nvidia.com/
currently intel-iommu driver already rejects 1) enforcing CC on a domain which is already attached to non-CC device and 2) attaching a non-CC device to a domain which has enforce_cc.
so there is no explorable bug to fix in stable tree.
I see. Thanks!