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

Robin Murphy
2026-02-03T18:59:41Z

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.