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.