Re: [RFC PATCH v2 12/15] vfio: Support VFIO devices that access the CPU MMU

[Ryan Roberts <ryan.roberts@arm.com>]

On 20/10/2026 16:13, Alex Williamson wrote:
> On Tue, 20 Oct 2026 16:06:37 +0100
> Ryan Roberts <ryan.roberts@arm.com> wrote:
> 
>> On 20/10/2026 15:09, Jason Gunthorpe wrote:
>>> On Tue, Oct 20, 2026 at 12:51:26PM +0100, Ryan Roberts wrote:  
>>>>> However.. you still have to affirm which single mm is the mm that the
>>>>> device is going to be doing DMA against. The process the opens the fd
>>>>> should not be forced to be the mm that it gets linked to.  
>>>>
>>>> What is the mm representing here? Ultimately we want to install the KVM
>>>> instance's stage2 pgtables and (pinned) VMID. We currently get that via the
>>>> bound KVM instance (which looks like it still works using the cdev interface?)
>>>>
>>>> The guest will then install the stage1 pgtables and (pinned) ASID associated
>>>> with the relevant (guest) mm_struct.
>>>>
>>>> Do we _need_ an mm association in the host?  
>>>
>>> Ah.. I see, I didn't quite follow that. OK.. Ah everyone else doing
>>> this is using iommufd with a viommu to establish their connection
>>> between device an KVM. eg Jacob Pan's series. That's a probably a
>>> better idea to stay aligned with the common path. Though your reasons
>>> are a little different..  
>>
>> Just to check, you're referring to [1]?
>>
>> I was under the impression that I could open the VFIO device through the cdev
>> interface, then bind it to the KVM instance via KVM_DEV_VFIO_FILE_ADD... Why do
>> I need an iommufd at all?
> 
> The cdev is not unlocked to actually access the device until it's bound
> to iommufd.  Thanks,

Ahh - got it! Thanks!

> 
> Alex