Bug 1546111

Summary:	vhost-user / Multiqueue: send virtio device status to the backend
Product:	Red Hat Enterprise Linux 9	Reporter:	Maxime Coquelin <maxime.coquelin>
Component:	qemu-kvm	Assignee:	lulu <lulu>
qemu-kvm sub component:	Networking	QA Contact:	Pei Zhang <pezhang>
Status:	CLOSED WONTFIX	Docs Contact:
Severity:	low
Priority:	medium	CC:	aadam, ailan, aliang, chayang, coli, juzhang, pezhang, rbalakri, virt-maint, xuwei
Version:	unspecified	Keywords:	Reopened, Triaged
Target Milestone:	pre-dev-freeze
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1548112 (view as bug list)		Environment:
Last Closed:	2022-01-26 07:27:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1548112

Description Maxime Coquelin 2018-02-16 10:53:54 UTC

Description of problem:

When the guest virtio driver does not initialize all queues declared
in QEMU cmdline, the vhost-user backend keeps waiting for informations
for the un-initialized queues and never starts the port.

Proposed change is to introduce a new vhost-user protocol request for
the master to send virtio device status updates to the slave.

Since virtio 1.0, queues are considered set up once the guest driver 
sets the DRIVER_OK bit in virtio device status.

For virtio < 1.0, a workaroiund has to be implemented since the driver
may start to process queues before setting DRIVER_OK, or even could
never set DRIVER_OK.

See Virtio specification chapters 3.1 & 3.1.1 for detailed information.

Version-Release number of selected component (if applicable):


How reproducible:

Start a Windows guest with more queue pairs declared in QEMU cmdline
than vCPUs. 

Actual results:

The driver only initializes as many queue pairs as vCPUs, whereas the
user backend waits for all qeueue pairs to be initialized to start the
port.

Expected results:

The user backend should start the port as soon as all initialized queues
are set up on backend side.

Additional info:

Comment 2 Maxime Coquelin 2018-02-22 18:40:32 UTC

QEMU RFC posted upstream:
http://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04560.html

Comment 9 Ademar Reis 2020-02-05 22:47:05 UTC

QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Comment 11 Maxime Coquelin 2020-10-19 10:28:05 UTC

Hi Cindy,

Assigning this Bz to you after discussion with Ariel.

This Bz is for the Vhost-user backend patches that dependeded on your Vhost-vDPA series:
https://patchwork.ozlabs.org/project/qemu-devel/patch/20200514073332.1434576-1-maxime.coquelin@redhat.com/

The spec part of this patch is already merged in upstream Qemu, the code part need to be rebased on top of the series you got merged.

Thanks,
Maxime

Comment 15 RHEL Program Management 2021-01-08 07:27:18 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 16 Pei Zhang 2021-01-25 07:16:54 UTC

Hello Ariel,

Do we plan to fix this bug ? Do we need to re-open it? Thanks.

Best regards,

Pei

Comment 19 lulu@redhat.com 2021-02-03 06:42:37 UTC

move this to 8.5 since we don't have enough time to catch the deadline

Comment 21 RHEL Program Management 2021-07-25 07:30:13 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 25 John Ferlan 2021-09-17 14:08:52 UTC

Bulk update: Move RHEL8 bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Comment 27 RHEL Program Management 2022-01-26 07:27:10 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.