]> git.ipfire.org Git - thirdparty/libvirt.git/commit
qemu_domain: Increase memlock limit for NVMe disks
authorMichal Privoznik <mprivozn@redhat.com>
Wed, 12 Apr 2023 15:15:08 +0000 (17:15 +0200)
committerMichal Privoznik <mprivozn@redhat.com>
Thu, 20 Apr 2023 06:37:22 +0000 (08:37 +0200)
commit5670c50ffb3cd999f0bee779bbaa8f7dc7b6e0e0
tree105a5da1fc568b2db9f0acca1fe4fd06caaf12b9
parent0d0604a51a5674e432335d201418cbba80899b73
qemu_domain: Increase memlock limit for NVMe disks

When starting QEMU, or when hotplugging a PCI device QEMU might
lock some memory. How much? Well, that's an undecidable problem.

But despite that, we try to guess. And it more or less works,
until there's a counter example. This time, it's a guest with
both <hostdev/> and an NVMe <disk/>. I've started a simple guest
with 4GiB of memory:

  # virsh dominfo fedora
  Max memory:     4194304 KiB
  Used memory:    4194304 KiB

And here are the amounts of memory that QEMU tried to lock,
obtained via:

  grep VmLck /proc/$(pgrep qemu-kvm)/status

  1) with just one <hostdev/>
     VmLck:   4194308 kB

  2) with just one NVMe <disk/>
     VmLck:   4328544 kB

  3) with one <hostdev/> and one NVMe <disk/>
     VmLck:   8522852 kB

Now, what's surprising is case 2) where the locked memory exceeds
the VM memory. It almost resembles VDPA. Therefore, treat is as
such.

Unfortunately, I don't have a box with two or more spare NVMe-s
so I can't tell for sure. But setting limit too tight means QEMU
refuses to start.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2014030
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
src/qemu/qemu_domain.c
tests/qemumemlockdata/qemumemlock-pc-hostdev-nvme.xml [new file with mode: 0644]
tests/qemumemlocktest.c