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

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Apr 25, 2022 at 02:56:39PM +0000, Parav Pandit wrote:
> 
> > 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?

There's no special errata process as far as I'm aware.
Feel free to peruse
https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26/


-- 
MST