[PATCH RFC v2 00/13] IOMMUFD Generic interface

[Laine Stump]

On 9/23/22 10:00 AM, Daniel P. Berrangé wrote:
> On Fri, Sep 23, 2022 at 10:46:21AM -0300, Jason Gunthorpe wrote:
>> On Fri, Sep 23, 2022 at 02:35:20PM +0100, Daniel P. Berrangé wrote:
>>> On Fri, Sep 23, 2022 at 10:29:41AM -0300, Jason Gunthorpe wrote:
>>>> On Fri, Sep 23, 2022 at 09:54:48AM +0100, Daniel P. Berrangé wrote:
>>>>
>>>>> Yes, we use cgroups extensively already.
>>>>
>>>> Ok, I will try to see about this
>>>>
>>>> Can you also tell me if the selinux/seccomp will prevent qemu from
>>>> opening more than one /dev/vfio/vfio ? I suppose the answer is no?
>>>
>>> I don't believe there's any restriction on the nubmer of open attempts,
>>> its just a case of allowed or denied globally for the VM.
>>
>> Ok
>>
>> For iommufd we plan to have qemu accept a single already opened FD of
>> /dev/iommu and so the selinux/etc would block all access to the
>> chardev.
> 
> A selinux policy update would be needed to allow read()/write() for the
> inherited FD, whle keeping open() blocked
> 
>> Can you tell me if the thing invoking qmeu that will open /dev/iommu
>> will have CAP_SYS_RESOURCE ? I assume yes if it is already touching
>> ulimits..
> 
> The privileged libvirtd runs with privs equiv to root, so all
> capabilities are present.
> 
> The unprivileged libvirtd runs with same privs as your user account,
> so no capabilities. I vaguely recall there was some way to enable
> use of PCI passthrough for unpriv libvirtd, but needed a bunch of
> admin setup steps ahead of time.

It's been a few years, but my recollection is that before starting a 
libvirtd that will run a guest with a vfio device, a privileged process 
needs to

1) increase the locked memory limit for the user that will be running 
qemu (eg. by adding a file with the increased limit to 
/etc/security/limits.d)

2) bind the device to the vfio-pci driver, and

3) chown /dev/vfio/$iommu_group to the user running qemu.