linux-kernel - Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260203175540.GC3931454@nvidia.com>
Date: Tue, 3 Feb 2026 13:55:40 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: dan.j.williams@...el.com, "Tian, Kevin" <kevin.tian@...el.com>,
	Jonathan Cameron <jonathan.cameron@...wei.com>,
	"will@...nel.org" <will@...nel.org>,
	"robin.murphy@....com" <robin.murphy@....com>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"joro@...tes.org" <joro@...tes.org>,
	"praan@...gle.com" <praan@...gle.com>,
	"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
	"miko.lenczewski@....com" <miko.lenczewski@....com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache
 capable devices

On Tue, Feb 03, 2026 at 09:45:17AM -0800, Nicolin Chen wrote:
> Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not
> allowed in general if require_direct=true. I assume this case can be
> an exception since there's no point in allowing a device that has no
> driver yet to access any reserved region?

If require_direct is set then we have to disable this mechanism..

I'm not sure exactly what to do about this as the require_direct comes
from the hypervisor in a CC VM and we probably don't want to give the
hypervisor this kind of escape hatch.

Perhaps we need to lock off to failure on CC VMs if this ever
happens..

But baremetal should just keep working how it always worked in this
case..

Jason