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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.