From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 25 Apr 2022 13:32:39 -0400 From: "Michael S. Tsirkin" Subject: Re: [virtio-dev] Re: queue_reset register polarity to improve Message-ID: <20220425125819-mutt-send-email-mst@kernel.org> References: <20220424023301-mutt-send-email-mst@kernel.org> <871qxl8k51.fsf@redhat.com> <20220425085415-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline To: Parav Pandit Cc: Cornelia Huck , "virtio-dev@lists.oasis-open.org" , Halil Pasic List-ID: On Mon, Apr 25, 2022 at 02:56:39PM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin > > 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