* [PATCH v1 0/1] Memory hotplug fix @ 2025-05-29 12:32 Danylo Vodopianov 2025-05-29 12:32 ` [PATCH v1 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov 0 siblings, 1 reply; 8+ messages in thread From: Danylo Vodopianov @ 2025-05-29 12:32 UTC (permalink / raw) To: thomas, aman.deep.singh, yuying.zhang, orika, mcoqueli, ckm, matan, david.marchand, mko-plv, sil-plv Cc: stephen, dev Hi everyone. We detected an issue with the memory hotplug feature and virtio devices while working with vitrio in DPDK.In general, the issue is around the user request VHOST_USER_SET_MEM_TABLE and locking queues for this request (https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n1512) When the vhost_user receives the request VHOST_USER_SET_MEM_TABLE, it locks queues only when the flag lock_all_qps is true(it is always true), AND the flag VIRTIO_DEV_VDPA_CONFIGURED is not set. https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n3181 In the case of a memory hot plug, the flag VIRTIO_DEV_VDPA_CONFIGURED is always set, and due to this, the queues are never locked while they are expected to be locked. https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n1512. The quick solution is to add the check for request type and do lock queues always if we have request VHOST_USER_SET_MEM_TABLE. Something like this, in general https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n3179 if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED) || request == VHOST_USER_SET_MEM_TABLE) { ... Danylo Vodopianov (1): vhost: handle virtqueue locking for memory hotplug lib/vhost/vhost_user.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 2.43.5 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v1 1/1] vhost: handle virtqueue locking for memory hotplug 2025-05-29 12:32 [PATCH v1 0/1] Memory hotplug fix Danylo Vodopianov @ 2025-05-29 12:32 ` Danylo Vodopianov 2025-06-02 8:19 ` [PATCH v2 " Danylo Vodopianov 0 siblings, 1 reply; 8+ messages in thread From: Danylo Vodopianov @ 2025-05-29 12:32 UTC (permalink / raw) To: thomas, aman.deep.singh, yuying.zhang, orika, mcoqueli, ckm, matan, david.marchand, mko-plv, sil-plv Cc: stephen, dev, Maxime Coquelin, Chenbo Xia For vDPA devices, virtqueues are not locked once the device has been configured. In the commit 5e8fcc60b59d ("vhost: enhance virtqueue access lock asserts"), the asserts were enhanced to trigger rte_panic functionality, preventing access to virtqueues without locking. However, this change introduced an issue where the memory hotplug mechanism, added in the commit 127f9c6f7b78 ("vhost: handle memory hotplug with vDPA devices"), no longer works. Since it expects for all queues are locked. During the initialization of a vDPA device, the driver sets the VIRTIO_DEV_VDPA_CONFIGURED flag, which prevents the vhost_user_lock_all_queue_pairs function from locking the virtqueues. This leads to the error: the VIRTIO_DEV_VDPA_CONFIGURED flag allows the use of the hotplug mechanism, but it fails because the virtqueues are not locked, while it expects to be locked for VHOST_USER_SET_MEM_TABLE in the table VHOST_MESSAGE_HANDLERS. This patch addresses the issue by enhancing the conditional statement to include a new condition. Specifically, when the device receives the VHOST_USER_SET_MEM_TABLE request, the virtqueues are locked to update the basic configurations and hotplug the guest memory. This fix does not impact access lock when vDPA driver is configured for other unnecessary message handlers. Manual memory configuring with "--socket-mem" option allows to avoid hotplug mechanism using. Signed-off-by: Danylo Vodopianov <dvo-plv@napatech.com> --- lib/vhost/vhost_user.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c index ec950acf97..16d03e1033 100644 --- a/lib/vhost/vhost_user.c +++ b/lib/vhost/vhost_user.c @@ -3178,7 +3178,13 @@ vhost_user_msg_handler(int vid, int fd) * would cause a dead lock. */ if (msg_handler != NULL && msg_handler->lock_all_qps) { - if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED)) { + /* Lock all queue pairs if the device is not configured for vDPA, + * or if it is configured for vDPA but the request is VHOST_USER_SET_MEM_TABLE. + * This ensures proper queue locking for memory table updates and guest + * memory hotplug. + */ + if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED) || + request == VHOST_USER_SET_MEM_TABLE) { vhost_user_lock_all_queue_pairs(dev); unlock_required = 1; } -- 2.43.5 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2 1/1] vhost: handle virtqueue locking for memory hotplug 2025-05-29 12:32 ` [PATCH v1 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov @ 2025-06-02 8:19 ` Danylo Vodopianov 2025-06-02 8:40 ` [PATCH v3 0/1] Memory hotplug fix Danylo Vodopianov 0 siblings, 1 reply; 8+ messages in thread From: Danylo Vodopianov @ 2025-06-02 8:19 UTC (permalink / raw) To: thomas, aman.deep.singh, yuying.zhang, orika, mcoqueli, ckm, matan, david.marchand, mko-plv, sil-plv Cc: stephen, dev, Maxime Coquelin, Chenbo Xia For vDPA devices, virtqueues are not locked once the device has been configured. In the commit 5e8fcc60b59d ("vhost: enhance virtqueue access lock asserts"), the asserts were enhanced to trigger rte_panic functionality, preventing access to virtqueues without locking. However, this change introduced an issue where the memory hotplug mechanism, added in the commit 127f9c6f7b78 ("vhost: handle memory hotplug with vDPA devices"), no longer works. Since it expects for all queues are locked. During the initialization of a vDPA device, the driver sets the VIRTIO_DEV_VDPA_CONFIGURED flag, which prevents the vhost_user_lock_all_queue_pairs function from locking the virtqueues. This leads to the error: the VIRTIO_DEV_VDPA_CONFIGURED flag allows the use of the hotplug mechanism, but it fails because the virtqueues are not locked, while it expects to be locked for VHOST_USER_SET_MEM_TABLE in the table VHOST_MESSAGE_HANDLERS. This patch addresses the issue by enhancing the conditional statement to include a new condition. Specifically, when the device receives the VHOST_USER_SET_MEM_TABLE request, the virtqueues are locked to update the basic configurations and hotplug the guest memory. This fix does not impact access lock when vDPA driver is configured for other unnecessary message handlers. Manual memory configuring with "--socket-mem" option allows to avoid hotplug mechanism using. Signed-off-by: Danylo Vodopianov <dvo-plv@napatech.com> --- lib/vhost/vhost_user.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c index ec950acf97..16d03e1033 100644 --- a/lib/vhost/vhost_user.c +++ b/lib/vhost/vhost_user.c @@ -3178,7 +3178,13 @@ vhost_user_msg_handler(int vid, int fd) * would cause a dead lock. */ if (msg_handler != NULL && msg_handler->lock_all_qps) { - if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED)) { + /* Lock all queue pairs if the device is not configured for vDPA, + * or if it is configured for vDPA but the request is VHOST_USER_SET_MEM_TABLE. + * This ensures proper queue locking for memory table updates and guest + * memory hotplug. + */ + if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED) || + request == VHOST_USER_SET_MEM_TABLE) { vhost_user_lock_all_queue_pairs(dev); unlock_required = 1; } -- 2.47.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v3 0/1] Memory hotplug fix 2025-06-02 8:19 ` [PATCH v2 " Danylo Vodopianov @ 2025-06-02 8:40 ` Danylo Vodopianov 2025-06-02 8:40 ` [PATCH v3 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov 0 siblings, 1 reply; 8+ messages in thread From: Danylo Vodopianov @ 2025-06-02 8:40 UTC (permalink / raw) To: thomas, aman.deep.singh, yuying.zhang, orika, mcoqueli, ckm, matan, david.marchand, mko-plv, sil-plv Cc: stephen, dev Hi everyone. We detected an issue with the memory hotplug feature and virtio devices while working with vitrio in DPDK.In general, the issue is around the user request VHOST_USER_SET_MEM_TABLE and locking queues for this request (https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n1512) When the vhost_user receives the request VHOST_USER_SET_MEM_TABLE, it locks queues only when the flag lock_all_qps is true(it is always true), AND the flag VIRTIO_DEV_VDPA_CONFIGURED is not set. https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n3181 In the case of a memory hot plug, the flag VIRTIO_DEV_VDPA_CONFIGURED is always set, and due to this, the queues are never locked while they are expected to be locked. https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n1512. The quick solution is to add the check for request type and do lock queues always if we have request VHOST_USER_SET_MEM_TABLE. Something like this, in general https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n3179 if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED) || request == VHOST_USER_SET_MEM_TABLE) { ... Danylo Vodopianov (1): vhost: handle virtqueue locking for memory hotplug lib/vhost/vhost_user.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 2.47.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v3 1/1] vhost: handle virtqueue locking for memory hotplug 2025-06-02 8:40 ` [PATCH v3 0/1] Memory hotplug fix Danylo Vodopianov @ 2025-06-02 8:40 ` Danylo Vodopianov 2025-06-02 8:50 ` [PATCH v4 0/1] Memory hotplug fix Danylo Vodopianov 0 siblings, 1 reply; 8+ messages in thread From: Danylo Vodopianov @ 2025-06-02 8:40 UTC (permalink / raw) To: thomas, aman.deep.singh, yuying.zhang, orika, mcoqueli, ckm, matan, david.marchand, mko-plv, sil-plv Cc: stephen, dev, Maxime Coquelin, Chenbo Xia For vDPA devices, virtqueues are not locked once the device has been configured. In the commit 5e8fcc60b59d ("vhost: enhance virtqueue access lock asserts"), the asserts were enhanced to trigger rte_panic functionality, preventing access to virtqueues without locking. However, this change introduced an issue where the memory hotplug mechanism, added in the commit 127f9c6f7b78 ("vhost: handle memory hotplug with vDPA devices"), no longer works. Since it expects for all queues are locked. During the initialization of a vDPA device, the driver sets the VIRTIO_DEV_VDPA_CONFIGURED flag, which prevents the vhost_user_lock_all_queue_pairs function from locking the virtqueues. This leads to the error: the VIRTIO_DEV_VDPA_CONFIGURED flag allows the use of the hotplug mechanism, but it fails because the virtqueues are not locked, while it expects to be locked for VHOST_USER_SET_MEM_TABLE in the table VHOST_MESSAGE_HANDLERS. This patch addresses the issue by enhancing the conditional statement to include a new condition. Specifically, when the device receives the VHOST_USER_SET_MEM_TABLE request, the virtqueues are locked to update the basic configurations and hotplug the guest memory. This fix does not impact access lock when vDPA driver is configured for other unnecessary message handlers. Manual memory configuring with "--socket-mem" option allows to avoid hotplug mechanism using. Signed-off-by: Danylo Vodopianov <dvo-plv@napatech.com> --- lib/vhost/vhost_user.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c index ec950acf97..16d03e1033 100644 --- a/lib/vhost/vhost_user.c +++ b/lib/vhost/vhost_user.c @@ -3178,7 +3178,13 @@ vhost_user_msg_handler(int vid, int fd) * would cause a dead lock. */ if (msg_handler != NULL && msg_handler->lock_all_qps) { - if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED)) { + /* Lock all queue pairs if the device is not configured for vDPA, + * or if it is configured for vDPA but the request is VHOST_USER_SET_MEM_TABLE. + * This ensures proper queue locking for memory table updates and guest + * memory hotplug. + */ + if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED) || + request == VHOST_USER_SET_MEM_TABLE) { vhost_user_lock_all_queue_pairs(dev); unlock_required = 1; } -- 2.47.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v4 0/1] Memory hotplug fix 2025-06-02 8:40 ` [PATCH v3 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov @ 2025-06-02 8:50 ` Danylo Vodopianov 2025-06-02 8:50 ` [PATCH v4 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov 0 siblings, 1 reply; 8+ messages in thread From: Danylo Vodopianov @ 2025-06-02 8:50 UTC (permalink / raw) To: thomas, aman.deep.singh, yuying.zhang, orika, mcoqueli, ckm, matan, david.marchand, mko-plv, sil-plv Cc: stephen, dev Hi everyone. We detected an issue with the memory hotplug feature and virtio devices while working with vitrio in DPDK.In general, the issue is around the user request VHOST_USER_SET_MEM_TABLE and locking queues for this request (https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n1512) When the vhost_user receives the request VHOST_USER_SET_MEM_TABLE, it locks queues only when the flag lock_all_qps is true(it is always true), AND the flag VIRTIO_DEV_VDPA_CONFIGURED is not set. https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n3181 In the case of a memory hot plug, the flag VIRTIO_DEV_VDPA_CONFIGURED is always set, and due to this, the queues are never locked while they are expected to be locked. https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n1512. The quick solution is to add the check for request type and do lock queues always if we have request VHOST_USER_SET_MEM_TABLE. Something like this, in general https://git.dpdk.org/dpdk-stable/tree/lib/vhost/vhost_user.c#n3179 if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED) || request == VHOST_USER_SET_MEM_TABLE) { ... Danylo Vodopianov (1): vhost: handle virtqueue locking for memory hotplug lib/vhost/vhost_user.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 2.47.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v4 1/1] vhost: handle virtqueue locking for memory hotplug 2025-06-02 8:50 ` [PATCH v4 0/1] Memory hotplug fix Danylo Vodopianov @ 2025-06-02 8:50 ` Danylo Vodopianov 2025-06-03 12:30 ` Maxime Coquelin 0 siblings, 1 reply; 8+ messages in thread From: Danylo Vodopianov @ 2025-06-02 8:50 UTC (permalink / raw) To: thomas, aman.deep.singh, yuying.zhang, orika, mcoqueli, ckm, matan, david.marchand, mko-plv, sil-plv Cc: stephen, dev, Maxime Coquelin, Chenbo Xia For vDPA devices, virtqueues are not locked once the device has been configured. In the commit 5e8fcc60b59d ("vhost: enhance virtqueue access lock asserts"), the asserts were enhanced to trigger rte_panic functionality, preventing access to virtqueues without locking. However, this change introduced an issue where the memory hotplug mechanism, added in the commit 127f9c6f7b78 ("vhost: handle memory hotplug with vDPA devices"), no longer works. Since it expects for all queues are locked. During the initialization of a vDPA device, the driver sets the VIRTIO_DEV_VDPA_CONFIGURED flag, which prevents the vhost_user_lock_all_queue_pairs function from locking the virtqueues. This leads to the error: the VIRTIO_DEV_VDPA_CONFIGURED flag allows the use of the hotplug mechanism, but it fails because the virtqueues are not locked, while it expects to be locked for VHOST_USER_SET_MEM_TABLE in the table VHOST_MESSAGE_HANDLERS. This patch addresses the issue by enhancing the conditional statement to include a new condition. Specifically, when the device receives the VHOST_USER_SET_MEM_TABLE request, the virtqueues are locked to update the basic configurations and hotplug the guest memory. This fix does not impact access lock when vDPA driver is configured for other unnecessary message handlers. Manual memory configuring with "--socket-mem" option allows to avoid hotplug mechanism using. Signed-off-by: Danylo Vodopianov <dvo-plv@napatech.com> --- lib/vhost/vhost_user.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c index ec950acf97..16d03e1033 100644 --- a/lib/vhost/vhost_user.c +++ b/lib/vhost/vhost_user.c @@ -3178,7 +3178,13 @@ vhost_user_msg_handler(int vid, int fd) * would cause a dead lock. */ if (msg_handler != NULL && msg_handler->lock_all_qps) { - if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED)) { + /* Lock all queue pairs if the device is not configured for vDPA, + * or if it is configured for vDPA but the request is VHOST_USER_SET_MEM_TABLE. + * This ensures proper queue locking for memory table updates and guest + * memory hotplug. + */ + if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED) || + request == VHOST_USER_SET_MEM_TABLE) { vhost_user_lock_all_queue_pairs(dev); unlock_required = 1; } -- 2.47.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 1/1] vhost: handle virtqueue locking for memory hotplug 2025-06-02 8:50 ` [PATCH v4 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov @ 2025-06-03 12:30 ` Maxime Coquelin 0 siblings, 0 replies; 8+ messages in thread From: Maxime Coquelin @ 2025-06-03 12:30 UTC (permalink / raw) To: Danylo Vodopianov, thomas, aman.deep.singh, yuying.zhang, orika, mcoqueli, ckm, matan, david.marchand, mko-plv, sil-plv Cc: stephen, dev, Chenbo Xia Hello Danylo, On 6/2/25 10:50 AM, Danylo Vodopianov wrote: > For vDPA devices, virtqueues are not locked once the device has been > configured. In the > commit 5e8fcc60b59d ("vhost: enhance virtqueue access lock asserts"), > the asserts were enhanced to trigger rte_panic functionality, preventing > access to virtqueues without locking. However, this change introduced > an issue where the memory hotplug mechanism, added in the > commit 127f9c6f7b78 ("vhost: handle memory hotplug with vDPA devices"), > no longer works. Since it expects for all queues are locked. > > During the initialization of a vDPA device, the driver sets the > VIRTIO_DEV_VDPA_CONFIGURED flag, which prevents the > vhost_user_lock_all_queue_pairs function from locking the > virtqueues. This leads to the error: the VIRTIO_DEV_VDPA_CONFIGURED > flag allows the use of the hotplug mechanism, but it fails > because the virtqueues are not locked, while it expects to be locked > for VHOST_USER_SET_MEM_TABLE in the table VHOST_MESSAGE_HANDLERS. > > This patch addresses the issue by enhancing the conditional statement > to include a new condition. Specifically, when the device receives the > VHOST_USER_SET_MEM_TABLE request, the virtqueues are locked to update > the basic configurations and hotplug the guest memory. > > This fix does not impact access lock when vDPA driver is configured > for other unnecessary message handlers. > > Manual memory configuring with "--socket-mem" option allows to avoid > hotplug mechanism using. s/using/use/ It needs a fixes tag, and stable@dpdk.org should be cc'ed, so that it gets backported to LTS branches. > > Signed-off-by: Danylo Vodopianov <dvo-plv@napatech.com> > --- > lib/vhost/vhost_user.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c > index ec950acf97..16d03e1033 100644 > --- a/lib/vhost/vhost_user.c > +++ b/lib/vhost/vhost_user.c > @@ -3178,7 +3178,13 @@ vhost_user_msg_handler(int vid, int fd) > * would cause a dead lock. > */ > if (msg_handler != NULL && msg_handler->lock_all_qps) { > - if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED)) { > + /* Lock all queue pairs if the device is not configured for vDPA, > + * or if it is configured for vDPA but the request is VHOST_USER_SET_MEM_TABLE. > + * This ensures proper queue locking for memory table updates and guest > + * memory hotplug. > + */ > + if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED) || > + request == VHOST_USER_SET_MEM_TABLE) { It looks like a workaround, and I'm afraid it could cause regression with some vDPA devices, or that it would not be enough and we would have to add other requests as exception. Wouldn't it better to modify VHOST_USER_ASSERT_LOCK() so that it takes into account the VIRTIO_DEV_VDPA_CONFIGURED flag? Thanks, Maxime > vhost_user_lock_all_queue_pairs(dev); > unlock_required = 1; > } ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-06-03 12:31 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-05-29 12:32 [PATCH v1 0/1] Memory hotplug fix Danylo Vodopianov 2025-05-29 12:32 ` [PATCH v1 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov 2025-06-02 8:19 ` [PATCH v2 " Danylo Vodopianov 2025-06-02 8:40 ` [PATCH v3 0/1] Memory hotplug fix Danylo Vodopianov 2025-06-02 8:40 ` [PATCH v3 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov 2025-06-02 8:50 ` [PATCH v4 0/1] Memory hotplug fix Danylo Vodopianov 2025-06-02 8:50 ` [PATCH v4 1/1] vhost: handle virtqueue locking for memory hotplug Danylo Vodopianov 2025-06-03 12:30 ` Maxime Coquelin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).