RE: [virtio-dev] Re: queue_reset register polarity to improve

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, April 25, 2022 9:43 AM
> 
> Question is what exactly is the advantage of making changes now.  If we are
> trying to save bits then maybe an alternative that uses queue enable instead
> should be worked on.
> 
Bit saving by merging to queue_enable is yet another gain.
But it may be too late now as you say.
If we adopt to the alternative definition we discussed, new queue_reset bit can follow queue_enable without additional complexity.

> 
> > Spec is not released, right?
> 
> Kind of yes. The vote to release for a review is technically ongoing, but
> practically 6 out of 8 voting members already cast a ballot and voted yes.
> The best way forward if you think the issue is important enough to delay the
> release is probably working on a proposal for a change meanwhile and
> submitting it as part of the 30 day public review. Since the change seems
> material this would imply another 15 day public review period, delaying the
> release by about a month in total.
> 
> As part of that I would suggest explaining the motivation for the change beyond
> the simple "seems a bit cleaner".
> 
To me it is beyond than being cleaner.
A state machine and driver-device interface where same register values coney different things doesn't look right.

If virtio spec release process has concept of errata/ratification, I propose a minor change that doesn't affect the current release.

a. Let feature bit as is
b. On queue_reset=1, it stays 1, until queue is busy in reset
c. When queue reset completed, it goes to zero along with queue_enabled bit.

I can draft the "Fixes" text for this in existing proposed spec. This way we get right fix without much disruption.
Would that be ok?