[libvirt] [PATCH 0/3] Fix memlock limit during hotplug of mdev devices
The routine qemuDomainGetMemLockLimitBytes() has a couple tests to determine what the maximum limit of locked memory should be. If I start a domain without any vfio stuff, /proc/$PID/limits says the limit is 64KiB. If I start a guest with a vfio-ccw hostdev, the limit is now $GUEST_MEMORY + 1GiB. It doesn't matter if I have one hostdev or a thousand; it's always 1GiB more than the configured amount of guest memory. If I start a guest without any vfio devices, and hotplug that same vfio-ccw hostdev, the limit remains at 64KiB and I start getting I/O errors in the guest. This makes sense, since some of the I/O chains are long enough to exceed that page limit, and the host starts throwing errors. There is already code that adjusts this limit during the hotplug of vfio-pci devices, so patch 1 refactors that code so that it can be re-used on the mdev hotplug path in patch 3. Patch 2, meanwhile, adds some cleanup that I think is missing in the vfio-pci path, based on my read of the mdev path. $ grep locked /proc/83543/limits Max locked memory 65536 65536 bytes $ virsh attach-device guest scratch-ca8b.xml Device attached successfully $ grep locked /proc/83543/limits Max locked memory 3221225472 3221225472 bytes Eric Farman (3): qemu: Refactor the max memlock routine qemu: Reset the maximum locked memory on hotplug fail qemu: Adjust max memlock on mdev hotplug src/qemu/qemu_domain.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 2 ++ src/qemu/qemu_hotplug.c | 22 ++++++++++++---------- 3 files changed, 44 insertions(+), 10 deletions(-) -- 2.17.1
Let's pull this hunk out into a function, so it can be reused in another codepath that needs to do the same thing. Signed-off-by: Eric Farman <farman@linux.ibm.com> --- src/qemu/qemu_domain.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 2 ++ src/qemu/qemu_hotplug.c | 11 +---------- 3 files changed, 33 insertions(+), 10 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index c7eb0b5e9a..a63a035328 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -11723,6 +11723,36 @@ qemuDomainAdjustMaxMemLock(virDomainObjPtr vm) return ret; } + +/** + * qemuDomainAdjustMaxMemLockHostdev: + * @vm: domain + * @hostdev: device + * + * Temporarily add the hostdev to the domain definition. This is needed + * because qemuDomainAdjustMaxMemLock() requires the hostdev to be already + * part of the domain definition, but other functions like + * qemuAssignDeviceHostdevAlias() expect it *not* to be there. + * A better way to handle this would be nice + * + * Returns: 0 on success, <0 on failure + */ +int +qemuDomainAdjustMaxMemLockHostdev(virDomainObjPtr vm, + virDomainHostdevDefPtr hostdev) +{ + int ret = 0; + + vm->def->hostdevs[vm->def->nhostdevs++] = hostdev; + if (qemuDomainAdjustMaxMemLock(vm) < 0) + ret = -1; + + vm->def->hostdevs[--(vm->def->nhostdevs)] = NULL; + + return ret; +} + + /** * qemuDomainHasVcpuPids: * @vm: Domain object diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index d097f23342..456c623336 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -931,6 +931,8 @@ void qemuDomainUpdateCurrentMemorySize(virDomainObjPtr vm); unsigned long long qemuDomainGetMemLockLimitBytes(virDomainDefPtr def); int qemuDomainAdjustMaxMemLock(virDomainObjPtr vm); +int qemuDomainAdjustMaxMemLockHostdev(virDomainObjPtr vm, + virDomainHostdevDefPtr hostdev); int qemuDomainDefValidateMemoryHotplug(const virDomainDef *def, virQEMUCapsPtr qemuCaps, diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 63acb9c451..24e75e49be 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1508,17 +1508,8 @@ qemuDomainAttachHostPCIDevice(virQEMUDriverPtr driver, break; } - /* Temporarily add the hostdev to the domain definition. This is needed - * because qemuDomainAdjustMaxMemLock() requires the hostdev to be already - * part of the domain definition, but other functions like - * qemuAssignDeviceHostdevAlias() used below expect it *not* to be there. - * A better way to handle this would be nice */ - vm->def->hostdevs[vm->def->nhostdevs++] = hostdev; - if (qemuDomainAdjustMaxMemLock(vm) < 0) { - vm->def->hostdevs[--(vm->def->nhostdevs)] = NULL; + if (qemuDomainAdjustMaxMemLockHostdev(vm, hostdev) < 0) goto error; - } - vm->def->hostdevs[--(vm->def->nhostdevs)] = NULL; if (qemuDomainNamespaceSetupHostdev(vm, hostdev) < 0) goto error; -- 2.17.1
On 9/3/19 5:09 PM, Eric Farman wrote:
Let's pull this hunk out into a function, so it can be reused in another codepath that needs to do the same thing.
Signed-off-by: Eric Farman <farman@linux.ibm.com> ---
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
src/qemu/qemu_domain.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 2 ++ src/qemu/qemu_hotplug.c | 11 +---------- 3 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index c7eb0b5e9a..a63a035328 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -11723,6 +11723,36 @@ qemuDomainAdjustMaxMemLock(virDomainObjPtr vm) return ret; }
+ +/** + * qemuDomainAdjustMaxMemLockHostdev: + * @vm: domain + * @hostdev: device + * + * Temporarily add the hostdev to the domain definition. This is needed + * because qemuDomainAdjustMaxMemLock() requires the hostdev to be already + * part of the domain definition, but other functions like + * qemuAssignDeviceHostdevAlias() expect it *not* to be there. + * A better way to handle this would be nice + * + * Returns: 0 on success, <0 on failure + */ +int +qemuDomainAdjustMaxMemLockHostdev(virDomainObjPtr vm, + virDomainHostdevDefPtr hostdev) +{ + int ret = 0; + + vm->def->hostdevs[vm->def->nhostdevs++] = hostdev; + if (qemuDomainAdjustMaxMemLock(vm) < 0) + ret = -1; + + vm->def->hostdevs[--(vm->def->nhostdevs)] = NULL; + + return ret; +} + + /** * qemuDomainHasVcpuPids: * @vm: Domain object diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index d097f23342..456c623336 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -931,6 +931,8 @@ void qemuDomainUpdateCurrentMemorySize(virDomainObjPtr vm);
unsigned long long qemuDomainGetMemLockLimitBytes(virDomainDefPtr def); int qemuDomainAdjustMaxMemLock(virDomainObjPtr vm); +int qemuDomainAdjustMaxMemLockHostdev(virDomainObjPtr vm, + virDomainHostdevDefPtr hostdev);
int qemuDomainDefValidateMemoryHotplug(const virDomainDef *def, virQEMUCapsPtr qemuCaps, diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 63acb9c451..24e75e49be 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1508,17 +1508,8 @@ qemuDomainAttachHostPCIDevice(virQEMUDriverPtr driver, break; }
- /* Temporarily add the hostdev to the domain definition. This is needed - * because qemuDomainAdjustMaxMemLock() requires the hostdev to be already - * part of the domain definition, but other functions like - * qemuAssignDeviceHostdevAlias() used below expect it *not* to be there. - * A better way to handle this would be nice */ - vm->def->hostdevs[vm->def->nhostdevs++] = hostdev; - if (qemuDomainAdjustMaxMemLock(vm) < 0) { - vm->def->hostdevs[--(vm->def->nhostdevs)] = NULL; + if (qemuDomainAdjustMaxMemLockHostdev(vm, hostdev) < 0) goto error; - } - vm->def->hostdevs[--(vm->def->nhostdevs)] = NULL;
if (qemuDomainNamespaceSetupHostdev(vm, hostdev) < 0) goto error;
If attaching a PCI hostdev fails, there are several things that need to be un-done as part of the cleanup. One thing that is not done is re-calculating/re-setting the maximum amount of locked memory for the domain, since we may have changed that. Let's fix that, just to ensure everything is back the way it was. Signed-off-by: Eric Farman <farman@linux.ibm.com> --- src/qemu/qemu_hotplug.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 24e75e49be..979e97b608 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1469,6 +1469,7 @@ qemuDomainAttachHostPCIDevice(virQEMUDriverPtr driver, bool teardowncgroup = false; bool teardownlabel = false; bool teardowndevice = false; + bool teardownmemlock = false; int backend; VIR_AUTOUNREF(virQEMUDriverConfigPtr) cfg = virQEMUDriverGetConfig(driver); unsigned int flags = 0; @@ -1510,6 +1511,7 @@ qemuDomainAttachHostPCIDevice(virQEMUDriverPtr driver, if (qemuDomainAdjustMaxMemLockHostdev(vm, hostdev) < 0) goto error; + teardownmemlock = true; if (qemuDomainNamespaceSetupHostdev(vm, hostdev) < 0) goto error; @@ -1577,6 +1579,8 @@ qemuDomainAttachHostPCIDevice(virQEMUDriverPtr driver, if (teardowndevice && qemuDomainNamespaceTeardownHostdev(vm, hostdev) < 0) VIR_WARN("Unable to remove host device from /dev"); + if (teardownmemlock && qemuDomainAdjustMaxMemLock(vm) < 0) + VIR_WARN("Unable to reset maximum locked memory on hotplug fail"); if (releaseaddr) qemuDomainReleaseDeviceAddress(vm, info); -- 2.17.1
On 9/3/19 5:09 PM, Eric Farman wrote:
If attaching a PCI hostdev fails, there are several things that need to be un-done as part of the cleanup. One thing that is not done is re-calculating/re-setting the maximum amount of locked memory for the domain, since we may have changed that.
Let's fix that, just to ensure everything is back the way it was.
Signed-off-by: Eric Farman <farman@linux.ibm.com> ---
Ouch. This is a bug fix that should be pushed regardless of the rest of the series, IMHO. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
src/qemu/qemu_hotplug.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 24e75e49be..979e97b608 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1469,6 +1469,7 @@ qemuDomainAttachHostPCIDevice(virQEMUDriverPtr driver, bool teardowncgroup = false; bool teardownlabel = false; bool teardowndevice = false; + bool teardownmemlock = false; int backend; VIR_AUTOUNREF(virQEMUDriverConfigPtr) cfg = virQEMUDriverGetConfig(driver); unsigned int flags = 0; @@ -1510,6 +1511,7 @@ qemuDomainAttachHostPCIDevice(virQEMUDriverPtr driver,
if (qemuDomainAdjustMaxMemLockHostdev(vm, hostdev) < 0) goto error; + teardownmemlock = true;
if (qemuDomainNamespaceSetupHostdev(vm, hostdev) < 0) goto error; @@ -1577,6 +1579,8 @@ qemuDomainAttachHostPCIDevice(virQEMUDriverPtr driver, if (teardowndevice && qemuDomainNamespaceTeardownHostdev(vm, hostdev) < 0) VIR_WARN("Unable to remove host device from /dev"); + if (teardownmemlock && qemuDomainAdjustMaxMemLock(vm) < 0) + VIR_WARN("Unable to reset maximum locked memory on hotplug fail");
if (releaseaddr) qemuDomainReleaseDeviceAddress(vm, info);
When starting a domain, we use the presence of a vfio-pci or mdev hostdev to determine if the memlock maximum needs to be increased. But if we hotplug either of these devices, only the vfio-pci path gets that love. This means that attaching a, say, vfio-ccw device will appear to succeed but the device may be unusable as the guest may see I/O errors on long CCW chains. The host, meanwhile, would be flooded with these messages: vfio_pin_page_external: Task qemu-system-s39 (11584) RLIMIT_MEMLOCK (65536) exceeded Let's adjust the maximum memlock value in the mdev hotplug path, so that the domain has the same value as if it were started with one or more mdev devices in its configuration. (Note: I started trying to refactor qemuDomainAdjustMaxMemLockHostdev() to address the "A better way to handle this would be nice" comment, but the result was getting way too involved for the problem I was trying to fix. Maybe another day.) Signed-off-by: Eric Farman <farman@linux.ibm.com> --- src/qemu/qemu_hotplug.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 979e97b608..ae7c5395d2 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -2755,6 +2755,7 @@ qemuDomainAttachMediatedDevice(virQEMUDriverPtr driver, bool teardowncgroup = false; bool teardownlabel = false; bool teardowndevice = false; + bool teardownmemlock = false; qemuDomainObjPrivatePtr priv = vm->privateData; virDomainDeviceDef dev = { VIR_DOMAIN_DEVICE_HOSTDEV, { .hostdev = hostdev } }; @@ -2798,6 +2799,10 @@ qemuDomainAttachMediatedDevice(virQEMUDriverPtr driver, if (VIR_REALLOC_N(vm->def->hostdevs, vm->def->nhostdevs + 1) < 0) goto cleanup; + if (qemuDomainAdjustMaxMemLockHostdev(vm, hostdev) < 0) + goto cleanup; + teardownmemlock = true; + qemuDomainObjEnterMonitor(driver, vm); ret = qemuMonitorAddDevice(priv->mon, devstr); if (qemuDomainObjExitMonitor(driver, vm) < 0) { @@ -2813,6 +2818,8 @@ qemuDomainAttachMediatedDevice(virQEMUDriverPtr driver, ret = 0; cleanup: if (ret < 0) { + if (teardownmemlock && qemuDomainAdjustMaxMemLock(vm) < 0) + VIR_WARN("Unable to reset maximum locked memory on hotplug fail"); if (teardowncgroup && qemuTeardownHostdevCgroup(vm, hostdev) < 0) VIR_WARN("Unable to remove host device cgroup ACL on hotplug fail"); if (teardownlabel && -- 2.17.1
On 9/3/19 5:09 PM, Eric Farman wrote:
When starting a domain, we use the presence of a vfio-pci or mdev hostdev to determine if the memlock maximum needs to be increased. But if we hotplug either of these devices, only the vfio-pci path gets that love. This means that attaching a, say, vfio-ccw device will appear to succeed but the device may be unusable as the guest may see I/O errors on long CCW chains. The host, meanwhile, would be flooded with these messages:
vfio_pin_page_external: Task qemu-system-s39 (11584) RLIMIT_MEMLOCK (65536) exceeded
Let's adjust the maximum memlock value in the mdev hotplug path, so that the domain has the same value as if it were started with one or more mdev devices in its configuration.
(Note: I started trying to refactor qemuDomainAdjustMaxMemLockHostdev() to address the "A better way to handle this would be nice" comment, but the result was getting way too involved for the problem I was trying to fix. Maybe another day.)
Signed-off-by: Eric Farman <farman@linux.ibm.com> ---
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
src/qemu/qemu_hotplug.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 979e97b608..ae7c5395d2 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -2755,6 +2755,7 @@ qemuDomainAttachMediatedDevice(virQEMUDriverPtr driver, bool teardowncgroup = false; bool teardownlabel = false; bool teardowndevice = false; + bool teardownmemlock = false; qemuDomainObjPrivatePtr priv = vm->privateData; virDomainDeviceDef dev = { VIR_DOMAIN_DEVICE_HOSTDEV, { .hostdev = hostdev } }; @@ -2798,6 +2799,10 @@ qemuDomainAttachMediatedDevice(virQEMUDriverPtr driver, if (VIR_REALLOC_N(vm->def->hostdevs, vm->def->nhostdevs + 1) < 0) goto cleanup;
+ if (qemuDomainAdjustMaxMemLockHostdev(vm, hostdev) < 0) + goto cleanup; + teardownmemlock = true; + qemuDomainObjEnterMonitor(driver, vm); ret = qemuMonitorAddDevice(priv->mon, devstr); if (qemuDomainObjExitMonitor(driver, vm) < 0) { @@ -2813,6 +2818,8 @@ qemuDomainAttachMediatedDevice(virQEMUDriverPtr driver, ret = 0; cleanup: if (ret < 0) { + if (teardownmemlock && qemuDomainAdjustMaxMemLock(vm) < 0) + VIR_WARN("Unable to reset maximum locked memory on hotplug fail"); if (teardowncgroup && qemuTeardownHostdevCgroup(vm, hostdev) < 0) VIR_WARN("Unable to remove host device cgroup ACL on hotplug fail"); if (teardownlabel &&
On Tue, Sep 03, 2019 at 10:09:48PM +0200, Eric Farman wrote:
When starting a domain, we use the presence of a vfio-pci or mdev hostdev to determine if the memlock maximum needs to be increased. But if we hotplug either of these devices, only the vfio-pci path gets that love. This means that attaching a, say, vfio-ccw device will appear to succeed but the device may be unusable as the guest may see I/O errors on long CCW chains. The host, meanwhile, would be flooded with these messages:
vfio_pin_page_external: Task qemu-system-s39 (11584) RLIMIT_MEMLOCK (65536) exceeded
Let's adjust the maximum memlock value in the mdev hotplug path, so that the domain has the same value as if it were started with one or more mdev devices in its configuration.
(Note: I started trying to refactor qemuDomainAdjustMaxMemLockHostdev() to address the "A better way to handle this would be nice" comment, but the result was getting way too involved for the problem I was trying to fix. Maybe another day.)
This paragraph doesn't belong into the commit message, I'll remove it before pushing. Otherwise looks good. Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Hi, I've thought about the issue you're fixing. Have you considered/tried to handle the MemLockLimit upper in the call hierarchy with your new qemuDomainAdjustMaxMemLockHostdev() function? Both qemuDomainAttachMediatedDevice() and qemuDomainAttachHostPCIDevice() are called from qemuDomainAttachHostDevice(). In theory, a call to qemuDomainAdjustMaxMemLockHostdev() at the start of AttachHostDevice() would cover all hostdev types of the function. Then you can undo the memLock in the 'error' label there if something goes wrong. It is possible to even argue about the be possibility of calling qemuDomainAdjustMaxMemLock() at the start of the generic hotplug function, qemuDomainAttachDeviceLive(), using the same principle - temporarily add the device in the vmdef, define the new mem limit assuming that everything will be OK, undo the adjustment if ret != 0. This would cover the case of memory hotplug, which needs RLIMIT changes as well and uses the same qemuDomainAdjustMaxMemLock() function to do it. This is more of a future work though. For now I believe it's appropriate to fix vfio-ccw hotplug ASAP. Thanks, DHB On 9/3/19 5:09 PM, Eric Farman wrote:
The routine qemuDomainGetMemLockLimitBytes() has a couple tests to determine what the maximum limit of locked memory should be. If I start a domain without any vfio stuff, /proc/$PID/limits says the limit is 64KiB. If I start a guest with a vfio-ccw hostdev, the limit is now $GUEST_MEMORY + 1GiB. It doesn't matter if I have one hostdev or a thousand; it's always 1GiB more than the configured amount of guest memory.
If I start a guest without any vfio devices, and hotplug that same vfio-ccw hostdev, the limit remains at 64KiB and I start getting I/O errors in the guest. This makes sense, since some of the I/O chains are long enough to exceed that page limit, and the host starts throwing errors.
There is already code that adjusts this limit during the hotplug of vfio-pci devices, so patch 1 refactors that code so that it can be re-used on the mdev hotplug path in patch 3.
Patch 2, meanwhile, adds some cleanup that I think is missing in the vfio-pci path, based on my read of the mdev path.
$ grep locked /proc/83543/limits Max locked memory 65536 65536 bytes $ virsh attach-device guest scratch-ca8b.xml Device attached successfully
$ grep locked /proc/83543/limits Max locked memory 3221225472 3221225472 bytes
Eric Farman (3): qemu: Refactor the max memlock routine qemu: Reset the maximum locked memory on hotplug fail qemu: Adjust max memlock on mdev hotplug
src/qemu/qemu_domain.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 2 ++ src/qemu/qemu_hotplug.c | 22 ++++++++++++---------- 3 files changed, 44 insertions(+), 10 deletions(-)
On 9/6/19 10:29 AM, Daniel Henrique Barboza wrote:
Hi,
I've thought about the issue you're fixing. Have you considered/tried to handle the MemLockLimit upper in the call hierarchy with your new qemuDomainAdjustMaxMemLockHostdev() function? Both qemuDomainAttachMediatedDevice() and qemuDomainAttachHostPCIDevice() are called from qemuDomainAttachHostDevice(). In theory, a call to
That's a good point. I did start going down that path, but that was before I created qemuDomainAdjustMaxMemLockHostdev() and didn't like the way things were turning out. I will revisit that, since it would certainly be better to have them adjusted in one place, rather than in the different qemuDomainAttach* routines that are affected now (or may be in the future).
qemuDomainAdjustMaxMemLockHostdev() at the start of AttachHostDevice() would cover all hostdev types of the function. Then you can undo the memLock in the 'error' label there if something goes wrong.
It is possible to even argue about the be possibility of calling qemuDomainAdjustMaxMemLock() at the start of the generic hotplug function, qemuDomainAttachDeviceLive(), using the same principle - temporarily add the device in the vmdef, define the new mem limit assuming that everything will be OK, undo the adjustment if ret != 0. This would cover the case of memory hotplug, which needs RLIMIT changes as well and uses the same qemuDomainAdjustMaxMemLock() function to do it.>
That would be excellent.
This is more of a future work though. For now I believe it's appropriate to fix vfio-ccw hotplug ASAP.
I agree. I have a few other things at the moment, but will look into these ideas after I get them sorted out. Thanks for the reviews, and the suggestions! - Eric
Thanks,
DHB
On 9/3/19 5:09 PM, Eric Farman wrote:
The routine qemuDomainGetMemLockLimitBytes() has a couple tests to determine what the maximum limit of locked memory should be. If I start a domain without any vfio stuff, /proc/$PID/limits says the limit is 64KiB. If I start a guest with a vfio-ccw hostdev, the limit is now $GUEST_MEMORY + 1GiB. It doesn't matter if I have one hostdev or a thousand; it's always 1GiB more than the configured amount of guest memory.
If I start a guest without any vfio devices, and hotplug that same vfio-ccw hostdev, the limit remains at 64KiB and I start getting I/O errors in the guest. This makes sense, since some of the I/O chains are long enough to exceed that page limit, and the host starts throwing errors.
There is already code that adjusts this limit during the hotplug of vfio-pci devices, so patch 1 refactors that code so that it can be re-used on the mdev hotplug path in patch 3.
Patch 2, meanwhile, adds some cleanup that I think is missing in the vfio-pci path, based on my read of the mdev path.
$ grep locked /proc/83543/limits Max locked memory 65536 65536 bytes $ virsh attach-device guest scratch-ca8b.xml Device attached successfully
$ grep locked /proc/83543/limits Max locked memory 3221225472 3221225472 bytes
Eric Farman (3): qemu: Refactor the max memlock routine qemu: Reset the maximum locked memory on hotplug fail qemu: Adjust max memlock on mdev hotplug
src/qemu/qemu_domain.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 2 ++ src/qemu/qemu_hotplug.c | 22 ++++++++++++---------- 3 files changed, 44 insertions(+), 10 deletions(-)
participants (3)
-
Daniel Henrique Barboza -
Eric Farman -
Pavel Hrdina