From: Cornelia Huck <cohuck@redhat.com>
To: Parav Pandit <parav@nvidia.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: "virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"hengqi@linux.alibaba.com" <hengqi@linux.alibaba.com>,
"xuanzhuo@linux.alibaba.com" <xuanzhuo@linux.alibaba.com>,
Shahaf Shuler <shahafs@nvidia.com>
Subject: RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage
Date: Mon, 23 Oct 2023 15:57:19 +0200 [thread overview]
Message-ID: <87zg09bfwg.fsf@redhat.com> (raw)
In-Reply-To: <PH0PR12MB5481D21AD4CD4C649C4E023FDCD8A@PH0PR12MB5481.namprd12.prod.outlook.com>
On Mon, Oct 23 2023, Parav Pandit <parav@nvidia.com> wrote:
> Hi Michael, Cornelia,
>
>> From: Parav Pandit
>> Sent: Thursday, October 19, 2023 7:27 PM
>>
>> Hi Cornelia, Michael,
>>
>> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
>> > open.org> On Behalf Of Parav Pandit
>> > Sent: Wednesday, October 18, 2023 4:43 PM
>> >
>> > > From: Cornelia Huck <cohuck@redhat.com>
>> > > Sent: Wednesday, October 18, 2023 4:34 PM
>> >
>> > > On Wed, Oct 18 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> > >
>> > > > On Wed, Oct 18, 2023 at 12:25:23PM +0200, Cornelia Huck wrote:
>> > > >> On Tue, Oct 17 2023, Parav Pandit <parav@nvidia.com> wrote:
>> > > >>
>> > > >> >> From: Cornelia Huck <cohuck@redhat.com>
>> > > >> >> Sent: Tuesday, October 17, 2023 5:55 PM
>> > > >> >>
>> > > >> >> On Mon, Oct 02 2023, Parav Pandit <parav@nvidia.com> wrote:
>> > > >> >> > +When VIRTIO_F_RING_DYNAMIC is not negotiated, the driver
>> > > >> >> > +MUST enable the required number of virtqueues before
>> > > >> >> > +setting the
>> > > DRIVER_OK status bit.
>> > > >> >>
>> > > >> >> What does "required" mean here? It just chooses to enable the
>> > > >> >> queues it wants to use, right?
>> > > >> > Right.
>> > > >> > Required meaning, whatever number of queues that driver choose
>> > > >> > to
>> > > enable, those must be enabled before driver_ok.
>> > > >> > So it is "required by the driver".
>> > > >> > Would that be ok?
>> > > >>
>> > > >> I'd write it as "the driver MUST enable any virtqueue it plans to use"
>> > > >> or something like that.
>> > > >>
>> > > >> (...)
>> > > >
>> > > > It would have to be SHOULD - we can't add new MUST requirements
>> > > > not contingent on a feature bit, we can give recommendation based
>> > > > on existing installed base.
>> > >
>> > It is not just installed base.
>> > Spec clearly says that:
>> > "Perform device-specific setup, including discovery of virtqueues for
>> > the device, optional per-bus setup, reading and possibly writing the
>> > device's virtio configuration space, and population of virtqueues."
>> >
>> > There is no feature bit or any text that says "population of
>> > virtqueues" can be done later outside of the device initialization phase.
>> > Only reference is _F_RESET bit which is only for re-enabling. (not enabling).
>> >
>> > > Then I wonder whether we need to add any normative statement at all
>> > > -- prior to the introduction of this new feature, the driver had to
>> > > enable anything it wanted to use before DRIVER_OK, and if it does
>> > > not negotiate the new feature, nothing changes. Spelling that out in
>> > > non-normative sections should be enough?
>> > It is already implied in the spec that queues must be enabled before
>> > DRIVER_OK.
>> > So what is written in normative is not changing any behavior.
>> > It is only making the implied behavior explicit.
>> >
>> > If it says SHOULD, that means, one can enable the queue for the first
>> > time after DRIVER_OK stage too.
>> > And that would violate the "Driver Requirements: Device Initialization".
>> >
>>
>> I have addressed the comments of v3 in v4 at [1].
>> The device requirement is kept as MUST to keep it aligned with the "driver
>> requirements section".'
>>
>> [1] https://lore.kernel.org/virtio-comment/20231017143135.758523-1-
>> parav@nvidia.com/T/#mc49b6e54186c5f1b1e8c743bc440ca0cc0938212
>>
>> Please review.
>
> If no comments in v4 which was a week ago, please raise the voting ballot.
Well, there are still comments from me here that post-date v4 (please
wait for a bit before posting another version!), so I'll continue
waiting for them to be addressed first.
>
> [1] https://lists.oasis-open.org/archives/virtio-comment/202310/msg00183.html
>
> Parav
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2023-10-23 13:57 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-02 5:15 [virtio-comment] [PATCH v3 0/2] Support enabling virtqueue after DRIVER_OK Parav Pandit
2023-10-02 5:16 ` [virtio-comment] [PATCH v3 1/2] conformance: Add missing virtqueue reset conformance references Parav Pandit
2023-10-05 16:53 ` Eugenio Perez Martin
2023-10-02 5:16 ` [virtio-comment] [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage Parav Pandit
2023-10-05 16:53 ` Eugenio Perez Martin
2023-10-12 6:39 ` [virtio-comment] " Xuan Zhuo
2023-10-17 12:25 ` Cornelia Huck
2023-10-17 12:48 ` [virtio-comment] " Parav Pandit
2023-10-18 10:25 ` Cornelia Huck
2023-10-18 10:28 ` Michael S. Tsirkin
2023-10-18 11:03 ` Cornelia Huck
2023-10-18 11:12 ` Michael S. Tsirkin
2023-10-18 11:12 ` Parav Pandit
2023-10-19 13:57 ` Parav Pandit
2023-10-23 13:29 ` Parav Pandit
2023-10-23 13:57 ` Cornelia Huck [this message]
2023-10-23 14:00 ` Parav Pandit
2023-10-23 14:27 ` Cornelia Huck
2023-10-23 14:53 ` Parav Pandit
2023-10-23 15:01 ` Cornelia Huck
2023-10-23 15:21 ` Parav Pandit
2023-10-25 9:55 ` Parav Pandit
2023-10-25 10:18 ` Cornelia Huck
2023-10-25 10:20 ` Parav Pandit
2023-10-25 10:24 ` Michael S. Tsirkin
2023-10-26 3:30 ` Parav Pandit
2023-10-26 5:39 ` Michael S. Tsirkin
2023-10-26 6:02 ` Parav Pandit
2023-10-26 6:24 ` Michael S. Tsirkin
2023-10-26 6:47 ` Parav Pandit
2023-10-26 8:27 ` Eugenio Perez Martin
2023-10-26 8:38 ` Parav Pandit
2023-10-26 9:15 ` Michael S. Tsirkin
2023-10-26 9:24 ` Parav Pandit
2023-10-26 9:27 ` Michael S. Tsirkin
2023-10-26 9:45 ` Parav Pandit
2023-10-27 10:13 ` Cornelia Huck
2023-10-27 10:28 ` Parav Pandit
2023-10-27 11:46 ` Cornelia Huck
2023-10-27 11:55 ` Parav Pandit
2023-10-26 9:18 ` Michael S. Tsirkin
2023-10-26 9:22 ` Parav Pandit
2023-10-26 9:26 ` Michael S. Tsirkin
2023-10-02 5:20 ` [virtio-comment] RE: [PATCH v3 0/2] Support enabling virtqueue after DRIVER_OK Parav Pandit
2023-10-10 4:57 ` Parav Pandit
2023-10-16 16:30 ` Parav Pandit
2023-10-17 11:58 ` Cornelia Huck
2023-10-17 12:50 ` Parav Pandit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zg09bfwg.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox