> On 20. Oct 2026, at 22:35, Demi Marie Obenour <[email protected]> wrote:
>
> On 10/20/26 11:06, Mohamed Mediouni wrote:
>>
>>> On 20. Oct 2026, at 16:20, Alex Bennée <[email protected]> wrote:
>>>
>>> Demi Marie Obenour <[email protected]> writes:
>>>
>>>> On 10/7/26 12:29, Alex Bennée wrote:
>>>
>>> (CC trimmed, IOMMU relevant maintainers added)
>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> The KVM/QEMU community call is at:
>>>>>
>>> <snip>
>>>>
>>>> Is this also for topics related to KVM but not necessarily QEMU?
>>>> If so, and if there will be people who are familiar with device
>>>> passthrough, I'd like to discuss whether IOMMU faults and KVM MMU
>>>> faults are recoverable. There is a virtio device I am working on
>>>> which requires this to avoid either crashing the guest or allowing
>>>> the guest to hog host memory.
>>>
>>> We didn't get to this at the last community call. Is this something that
>>> can be discussed on list first?
>>
>> It should be I think.
>>
>> Hi,
>>
>> For such a virtio device (and granularly exposing it to user contexts too),
>> is ATS + PRI
>> a good choice? Perhaps even using the host page tables directly, with a
>> per-process
>> abstraction as the security boundary.> > On physical hardware as intended,
>> outside of the ATS + PRI case, IOMMU faults
>> are expected to be something requiring a device/driver reset. On Arm however,
>> there’s an exception for the stall model, which pre-dates ATS + PRI.
>>
>> A PRI PPR reply of not present isn’t equivalent to an IOMMU fault and isn’t
>> expected to
>> result in a crash resulting in a device reset.
>
> I have two concerns with ATS + PRI:
>
> 1. ATS allows a device to bypass the IOMMU, and my project relies on
> the IOMMU to isolate a compromised device.
Hi,
For the hw side:
There are hardware mitigations for these in the sense of only allowing
pages to be addressed if they were supposed to be accessible (Arm DPT, tied
as part of the RME story)
Or what is also out there and often preferred is relying on PCIe IDE +
attestation instead…
>
> 2. I need to support both consumer and enterprise hardware. I suspect
> that ATS support is very limited in the consumer space.
PCIe ATS (at least in-SoC) is how AMD NPUs are deployed today, and the Intel
in-SoC accelerators rely on it too (via SVA):
https://www.kernel.org/doc/html/next/x86/sva.html
But for a synthetic device implemented in the hypervisor stack for the guest
that’s not going
to be an issue.
>
> For more context, I'm working on a device that allows a backend VM
> to provide virtio devices to other (frontend) VMs. The backend VM
> will often have an assigned PCIe device,
Hm, and you want that backend VM to not be able to access to all guest memory?
> and there are applications
> where zero-copy I/O would be very helpful for performance.
>
> However, when the frontend VM exits or unmaps memory, the memory
> also needs to be unmapped from the backend. If this is cooperative,
> the backend may simply refuse to cooperate, causing a host-side
> memory leak.
So “stealing” memory from the frontend VM to be a shared region with the
backend? With
an aim that all other guest memory remains inaccessible?
> If it is preemptive, the backend will take faults when
> it tries to access the memory that has been unmapped from it.
>
> One can avoid both problems by only letting the backend access a small
> buffer, but this requires a copy in either the frontend or the device.
In practice, bounce buffering here can end up meaning both…
Given your use case, I’m not sure if emulating ATS + PRI is the right thing to
do,
but it’s the only on-demand memory mapping support in the PCIe specification
today.
In your case it might mean having the IOMMU implementation as part of your TCB
so that
the device emulator is only able to map guest pages through the IOMMU
implementation
in your VMM...
> This might make the system uncompetitive with host-side vhost-user
> devices in high-performance applications.
>
> Is there a way around this tradeoff, or is zero copy incompatible
> with protecting both the backend and the host?
I don’t have much visibility on something else that’d be portable across
platforms unfortunately. In the CoCo cases what I’ve seen being deployed
ends up being either bounce buffering for passed through devices or PCIe
IDE with attestation and the NIC being trusted...
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
