On 12/2/19 9:26 AM, Michal Privoznik wrote: > In near future, the decision what to do with /dev/vfio/vfio with > respect to domain namespace and CGroup is going to be moved out > of qemuDomainGetHostdevPath() because there will be some other > types of devices than hostdevs that need access to VFIO. > > All functions that I'm changing (except qemuSetupHostdevCgroup()) > assume that hostdev we are adding/removing to VM is not in the > definition yet (because of how qemuDomainNeedsVFIO() is written). > Fortunately, this assumption is true. > > For qemuSetupHostdevCgroup(), the worst thing that may happen is > that we allow /dev/vfio/vfio which was already allowed. > > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > --- > src/qemu/qemu_cgroup.c | 47 +++++++++++++++++++++++++++++++++++++++++- > src/qemu/qemu_domain.c | 36 ++++++++++++++++++++++++++++++++ > 2 files changed, 82 insertions(+), 1 deletion(-) > > diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c > index 31cf71146b..65b148cd83 100644 > --- a/src/qemu/qemu_cgroup.c > +++ b/src/qemu/qemu_cgroup.c > @@ -25,6 +25,7 @@ > #include "qemu_domain.h" > #include "qemu_process.h" > #include "qemu_extdevice.h" > +#include "qemu_hostdev.h" > #include "virlog.h" > #include "viralloc.h" > #include "virerror.h" > @@ -359,6 +360,17 @@ qemuTeardownInputCgroup(virDomainObjPtr vm, > } > > > +/** > + * qemuSetupHostdevCgroup: > + * vm: domain object > + * @dev: device to allow > + * > + * For given host device @dev allow access to in Cgroups. > + * Note, @dev must not be in @vm's definition. > + * This last line should be dropped, it is still called like that via qemuSetupDevicesCgroup > + * Returns: 0 on success, > + * -1 otherwise. > + */ > int > qemuSetupHostdevCgroup(virDomainObjPtr vm, > virDomainHostdevDefPtr dev) > @@ -385,6 +397,16 @@ qemuSetupHostdevCgroup(virDomainObjPtr vm, > goto cleanup; > } > Maybe just add a comment here explaining that, at VM startup, this can lead to /dev/vfio/vfio being added to the cgroup multiple times, but that has never shown to be a problem. Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> - Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
