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: <0472f0f6-2f13-459e-857d-d5003f2f0ac4@arm.com>
Date: Tue, 3 Feb 2026 18:59:35 +0000
From: Robin Murphy <robin.murphy@....com>
To: Jason Gunthorpe <jgg@...dia.com>, 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>,
 "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 2026-02-03 5:55 pm, Jason Gunthorpe wrote:
> 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?

No, the point of RMRs in general is that the device can be assumed to 
already be accessing them, and that access must be preserved, regardless 
of whether an OS driver may or may not take over the device later. In 
fact RMRs with the "Remapping Permitted" flag are only strictly needed 
*until* an OS driver has taken control over whatever it was that 
firmware left them doing.

> 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..

Realistically this combination cannot exist bare-metal, since if the 
device requires to send ATS TT's to access an RMR then the SMMU would 
have to be enabled pre-boot, so then the RMR means we cannot ever 
disable it to reconfigure, so we'd be stuffed from the start...

Even though it's potentially a little more plausible in a VM where the 
underlying S2 would satisfy ATS, for much the same reason it's still 
going to look highly suspect from the VM's point of view to be presented 
with a device whose apparent ability to perform ATS traffic through a 
supposedly-disabled S1 SMMU must not be disrupted. However I think there 
would be no point exposing the ATS details to the VM to begin with. It's 
the host's decision to trust the device to play in the translated PA 
space and system cache coherency protocol, and no guest would be allowed 
to mess with those aspects either way, so there seems no obvious good 
reason for them to know at all.

Thanks,
Robin.