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.
