On 03/07/2016 09:20 AM, Kothapally Madhu Pavan wrote:
> When the hostdev managed=true, the VFIO devices are reattached
> to the host driver before coming to qemuTeardownHostdevCgroup().
> So, the /dev/vfio/<iommu> path would not exist. We ignore the
> EACCES error here.
>
> Signed-off-by: Kothapally Madhu Pavan <kmp@xxxxxxxxxxxxxxxxxx>
> ---
> src/qemu/qemu_cgroup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Can you show the error in the system log that you get when/if this
fails? Using EACCES implies to a permission error. The check in
virCgroupDenyDevicePath is:
if (stat(path, &sb) < 0) {
if (errno == EACCES && ignoreEacces)
return 1;
virReportSystemError(errno,
_("Path '%s' is not accessible"),
path);
return -1;
}
If the path doesn't exist, then it should be a different error message
(ENOENT perhaps).
My other question would be, if you follow the attachment path, you'll
see that if qemuHostdevPreparePCIDevices is successfully called, then
qemuSetupHostdevCgroup is called after (and virCgroupAllowDevicePath is
called).
So, shouldn't the corollary be qemuTeardownHostdevCgroup followed by
device reattachment. IOW:
e.g, move the qemuTeardownHostdevCgroup in qemuDomainRemoveHostDevice to
before the switch to qemuDomainRemove*HostDevice? I'd even think the
StoreHostdevLabel call could move. None of the calls would head into an
error path...
I've posted a couple of patches which do this, see:
http://www.redhat.com/archives/libvir-list/2016-March/msg01270.html
John
> diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
> index c76d585..2850346 100644
> --- a/src/qemu/qemu_cgroup.c
> +++ b/src/qemu/qemu_cgroup.c
> @@ -427,7 +427,7 @@ qemuTeardownHostdevCgroup(virDomainObjPtr vm,
>
> VIR_DEBUG("Cgroup deny %s for PCI device assignment", path);
> rv = virCgroupDenyDevicePath(priv->cgroup, path,
> - VIR_CGROUP_DEVICE_RWM, false);
> + VIR_CGROUP_DEVICE_RWM, dev->managed);
> virDomainAuditCgroupPath(vm, priv->cgroup,
> "deny", path, "rwm", rv == 0);
> if (rv < 0)
>
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list