[libvirt] [RFC PATCH v2 14.5/18] qemu: Bump the memory locking limit for mdevs as well

Erik Skultety posted 1 patch 4 years, 2 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/d9c1c616b7909e6b2c3840ea3ed8d62b7876582c.1487262664.git.eskultet@redhat.com
src/qemu/qemu_domain.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

[libvirt] [RFC PATCH v2 14.5/18] qemu: Bump the memory locking limit for mdevs as well

Posted by Erik Skultety 4 years, 2 months ago
Since mdevs are just another type of VFIO devices, we should increase
the memory locking limit the same way we do for VFIO PCI devices.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
---
 src/qemu/qemu_domain.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index eb86385..bdd687f 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -6222,11 +6222,12 @@ qemuDomainRequiresMemLock(virDomainDefPtr def)
         return true;
 
     for (i = 0; i < def->nhostdevs; i++) {
-        virDomainHostdevDefPtr dev = def->hostdevs[i];
+        virDomainHostdevSubsysPtr subsys = &def->hostdevs[i]->source.subsys;
 
-        if (dev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
-            dev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
-            dev->source.subsys.u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)
+        if (def->hostdevs[i]->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
+            (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV ||
+             (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
+              subsys->u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)))
             return true;
     }
 
-- 
2.10.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH v2 14.5/18] qemu: Bump the memory locking limit for mdevs as well

Posted by Alex Williamson 4 years, 2 months ago
On Thu, 16 Feb 2017 17:49:45 +0100
Erik Skultety <eskultet@redhat.com> wrote:

> Since mdevs are just another type of VFIO devices, we should increase
> the memory locking limit the same way we do for VFIO PCI devices.
> 
> Signed-off-by: Erik Skultety <eskultet@redhat.com>
> ---
>  src/qemu/qemu_domain.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index eb86385..bdd687f 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -6222,11 +6222,12 @@ qemuDomainRequiresMemLock(virDomainDefPtr def)
>          return true;
>  
>      for (i = 0; i < def->nhostdevs; i++) {
> -        virDomainHostdevDefPtr dev = def->hostdevs[i];
> +        virDomainHostdevSubsysPtr subsys = &def->hostdevs[i]->source.subsys;
>  
> -        if (dev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> -            dev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> -            dev->source.subsys.u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)
> +        if (def->hostdevs[i]->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> +            (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV ||
> +             (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> +              subsys->u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)))
>              return true;
>      }
>  

Nice!  For series:

Tested-by: Alex Williamson <alex.williamson@redhat.com>

(with KVMGT vGPU mdev)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH v2 14.5/18] qemu: Bump the memory locking limit for mdevs as well

Posted by Alex Williamson 4 years, 2 months ago
On Thu, 16 Feb 2017 11:04:39 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:

> On Thu, 16 Feb 2017 17:49:45 +0100
> Erik Skultety <eskultet@redhat.com> wrote:
> 
> > Since mdevs are just another type of VFIO devices, we should increase
> > the memory locking limit the same way we do for VFIO PCI devices.
> > 
> > Signed-off-by: Erik Skultety <eskultet@redhat.com>
> > ---
> >  src/qemu/qemu_domain.c | 9 +++++----
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> > index eb86385..bdd687f 100644
> > --- a/src/qemu/qemu_domain.c
> > +++ b/src/qemu/qemu_domain.c
> > @@ -6222,11 +6222,12 @@ qemuDomainRequiresMemLock(virDomainDefPtr def)
> >          return true;
> >  
> >      for (i = 0; i < def->nhostdevs; i++) {
> > -        virDomainHostdevDefPtr dev = def->hostdevs[i];
> > +        virDomainHostdevSubsysPtr subsys = &def->hostdevs[i]->source.subsys;
> >  
> > -        if (dev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> > -            dev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> > -            dev->source.subsys.u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)
> > +        if (def->hostdevs[i]->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> > +            (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV ||
> > +             (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> > +              subsys->u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)))
> >              return true;
> >      }
> >    
> 
> Nice!  For series:
> 
> Tested-by: Alex Williamson <alex.williamson@redhat.com>
> 
> (with KVMGT vGPU mdev)

Nit, if I configure a VM for an invalid mdev uuid, I get the following
error message:

Error starting domain: Requested operation is not valid: mediated devices are not supported by this kernel

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1404, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1035, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: Requested operation is not valid: mediated devices are not supported by this kernel

In this case it should really just be a device not found error, the
speculation that the kernel doesn't support mediated devices is
incorrect.  Thanks,

Alex

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH v2 14.5/18] qemu: Bump the memory locking limit for mdevs as well

Posted by Erik Skultety 4 years, 2 months ago
> > Nice!  For series:
> > 
> > Tested-by: Alex Williamson <alex.williamson@redhat.com>
> > 
> > (with KVMGT vGPU mdev)
> 

Thank you very much for the effort Alex. Given its current state, I'm glad
KVMGT was testable with my patches :).

> Nit, if I configure a VM for an invalid mdev uuid, I get the following
> error message:
> 
> Error starting domain: Requested operation is not valid: mediated devices are not supported by this kernel
> 
> Traceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
>     callback(asyncjob, *args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb
>     callback(*args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
>     ret = fn(self, *args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/domain.py", line 1404, in startup
>     self._backend.create()
>   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1035, in create
>     if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
> libvirtError: Requested operation is not valid: mediated devices are not supported by this kernel
> 
> In this case it should really just be a device not found error, the
> speculation that the kernel doesn't support mediated devices is
> incorrect.  Thanks,
> 

Noted, I'll address this as part of, presumably, v3 when I get a patch
review.

Thanks,
Erik

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list