** Description changed: [impact] when using qemu with interfaces that use the vhost_user backend (i.e. dpdk), there is a hardcoded limit of 8 memory regions that the vhost_user backend driver can support. This hardcoded limit is still present upstream, and appears to be a limitation of the vhost-user specification's "set mem table" protocol. There are some optimization and bugfixes in code over time, and in particular there is a very recent upstream commit (27598393a23215cfbf92ad550b9541675b0b8f2b) that allows increasing this max, however the vhost-user backend (that qemu talks to) must support and negotiate to use the new method. [test case] start a qemu guest with at least one vhost-user interface, and more than 8 discontiguous memory regions (which may result from multiple passthrough pci devices or other causes). The vhost-user device will fail to init due to exceeding its max memory region limit. [regression potential] tbd [scope] this limit still exists upstream, and appears to be a vhost-user specification protocol limit, so the only resolution may to be to switch to the new protocol feature added in the upstream commit referenced in the impact section. thus, any change would likely be needed in all releases, but as the new protocol feature is not a bug fix, but a new feature, it's unlikely it would qualify for backporting to any/all SRU releases. however, see other info section. [other info] there are at least some, and possibly multiple, bugfixes through the versions in x/b/f that improve how vhost ignores some memory regions, and merges contiguous regions, so it's possible the limit of 8 could be reached for some guests that fail on older releases. tbd identifying any/all such patches that might help. + + note some upstream patches that help with this bug, but do not actually + increase the limit of 8, are in bug 1887525
** Description changed: [impact] when using qemu with interfaces that use the vhost_user backend (i.e. dpdk), there is a hardcoded limit of 8 memory regions that the vhost_user backend driver can support. This hardcoded limit is still present upstream, and appears to be a limitation of the vhost-user specification's "set mem table" protocol. There are some optimization and bugfixes in code over time, and in particular there is a very recent upstream commit (27598393a23215cfbf92ad550b9541675b0b8f2b) that allows increasing this max, however the vhost-user backend (that qemu talks to) must support and negotiate to use the new method. [test case] start a qemu guest with at least one vhost-user interface, and more than 8 discontiguous memory regions (which may result from multiple passthrough pci devices or other causes). The vhost-user device will fail to init due to exceeding its max memory region limit. [regression potential] tbd [scope] this limit still exists upstream, and appears to be a vhost-user specification protocol limit, so the only resolution may to be to switch to the new protocol feature added in the upstream commit referenced in the impact section. thus, any change would likely be needed in all releases, but as the new protocol feature is not a bug fix, but a new feature, it's unlikely it would qualify for backporting to any/all SRU releases. however, see other info section. [other info] there are at least some, and possibly multiple, bugfixes through the versions in x/b/f that improve how vhost ignores some memory regions, and merges contiguous regions, so it's possible the limit of 8 could be reached for some guests that fail on older releases. tbd identifying any/all such patches that might help. note some upstream patches that help with this bug, but do not actually increase the limit of 8, are in bug 1887525 + + for reference, the vhost-user api function that imposes this limit: + https://www.qemu.org/docs/master/interop/vhost-user.html#memory-regions-description -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1886704 Title: qemu fails to init vhost_user if > 8 memory regions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1886704/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
