| 2020-07-07 18:32:10 |
Dan Streetman |
bug |
|
|
added bug |
| 2020-07-08 08:22:28 |
Paride Legovini |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2020-07-14 14:12:51 |
Dan Streetman |
description |
[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. |
[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 |
|
| 2020-07-14 14:16:07 |
Dan Streetman |
description |
[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 |
[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 |
|
| 2020-07-19 01:31:00 |
Rafael David Tinoco |
bug |
|
|
added subscriber Rafael David Tinoco |
| 2020-07-19 01:31:11 |
Rafael David Tinoco |
bug |
|
|
added subscriber Ubuntu Server |
| 2021-01-11 16:39:08 |
Dan Streetman |
nominated for series |
|
Ubuntu Groovy |
|
| 2021-01-11 16:39:08 |
Dan Streetman |
bug task added |
|
qemu (Ubuntu Groovy) |
|
| 2021-01-11 16:39:08 |
Dan Streetman |
nominated for series |
|
Ubuntu Focal |
|
| 2021-01-11 16:39:08 |
Dan Streetman |
bug task added |
|
qemu (Ubuntu Focal) |
|
| 2021-01-11 16:39:08 |
Dan Streetman |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-01-11 16:39:08 |
Dan Streetman |
bug task added |
|
qemu (Ubuntu Bionic) |
|
| 2021-01-11 16:39:08 |
Dan Streetman |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-01-11 16:39:08 |
Dan Streetman |
bug task added |
|
qemu (Ubuntu Hirsute) |
|
| 2021-01-11 16:39:15 |
Dan Streetman |
qemu (Ubuntu Hirsute): status |
New |
Fix Released |
|
| 2021-01-11 16:39:19 |
Dan Streetman |
qemu (Ubuntu Groovy): status |
New |
Won't Fix |
|
| 2021-01-11 16:39:23 |
Dan Streetman |
qemu (Ubuntu Bionic): status |
New |
Won't Fix |
|
| 2021-01-11 16:39:26 |
Dan Streetman |
qemu (Ubuntu Focal): status |
New |
Won't Fix |
|
