virtio device queue_reset polarity to be improved

[paravmellanox]

A recently defined queue_reset register has a little weird definition that we should improve.
When driver initiate queue reset, it writes queue_reset = 1.
When device is busy resetting the queue, on this driver request, it is expected to return queue_reset=0.
Once queue reset is completed it is expected to return queue_reset = 1.
(Polarity changed twice to same value as what was driver set). See more below.

So state wise,

q_enable, q_reset represents :

a) 0,0 -> device init time value
b) 1,0 -> vq is enabled by driver and working
c) 1,1 -> vq is enabled, driver initiated reset
d) 0,0 -> queue reset is ongoing
conflicts with #a, because queue is still enabled in device
whose reset is in progress.
External entity has no knowledge if VQ is undergoing reset or
VQ is never enabled.
e) 0,1 -> queue reset is completed (conflicts with #a initial value)

Instead, I think we should have below better, consistent definition, no matter how queue reset occurs (init time or later).

option-1:
q_enable, q_reset
A) 0, 0 -> default, device init time
B) 1, 0 -> driver has enabled vq
C) 1, 1 -> driver started q reset
D) 1, 1 -> q_reset stays 1 until device is busy resetting vq (communicating that its working on resetting, consistent with #C)
E) 0, 0 -> q_reset by device is completed, q got disabled (now matches the state same as device init time #A)

option-2:
When VIRTIO_F_RING_RESET flag is negotiated, writing queue_enable of 0 is allowed. device communicates that queue reset is completed when this bit turns 0 after writing 1.

Both options enable burning another 16-bit PCI register (to communicate one bit) that must be implemented in on-chip memory, because queue reset state is aligned with the queue_enable bit.

secondly,
Due described problem,
when a virtio device register state for queue_eanble = 1 and queue_reset = 0, a hypervisor system, reading device values cannot differentiate if the device VQ is under reset (ongoing reset) or reset never started.
This is because 1,0 state (queue reset ongoing) is same as state #B above.
This bug requires nasty workarounds in driver in the future virtio device live migration flow and certain hardware based devices needs to maintain extra bits to further workaround this.
It isn't elegant to start having workarounds on the specification not yet released. Lets please fix this.

Proposal:
https://lists.oasis-open.org/archives/virtio-comment/202204/msg00119.html

[paravmellanox]

secondly,
Due described problem,
when a virtio device register state for queue_eanble = 1 and queue_reset = 0, a hypervisor system, reading device values cannot differentiate if the device VQ is under reset (ongoing reset) or reset never started.
This is because 1,0 state (queue reset ongoing) is same as state #B above.
This bug requires nasty workarounds in driver in the future virtio device live migration flow and certain hardware based devices needs to maintain extra bits to further workaround this.
It isn't elegant to start having workarounds on the specification not yet released. Lets please fix this.

[mstsirkin]

Ballot started https://www.oasis-open.org/committees/ballot.php?id=3694