[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] RE: [PATCH 1/2] virtio: introduce selective queue enabling
On Thu, Jun 08, 2023 at 01:53:32PM +0200, Eugenio Perez Martin wrote: > On Tue, Jun 6, 2023 at 9:25âPM Parav Pandit <parav@nvidia.com> wrote: > > > > > From: Michael S. Tsirkin <mst@redhat.com> > > > Sent: Tuesday, June 6, 2023 3:20 PM > > > > > > > > Can you please highlight, current spec normative which indicates that > > > > all queues must be enabled before DRIVER_OK and more queues cannot be > > > > enabled after DRIVER_OK? > > > > > > > > > This one: > > > \drivernormative{\subsection}{Device Initialization}{General Initialization And > > > Device Operation / Device Initialization} > > > > > > it does not say "all queues" if you want to split hairs but I think assuming it's > > > safe to enable queues later is dangerous. > > > > > Yes, I have read it few times and every time I concluded that: > > it does not say that it must be done before DRIVER_OK and cannot be done after DRIVER_OK. > > > > I also read it this way to be honest. You have been doing spec lawyering for too long, take a step back, take a walk, then look at it from common sense POV. Well spec says: you MUST follow this order: - A - B - C can one conclude that if C triggers then B already happened? I would conclude yes. and just because it does not say *and do not do it in any other order* you are saying - A - C - B is also allowed? MUST follow this rule to me means "and do not violate this rule". > From a POV, to allow it if a > device does not handle it could be considered a fix, rather than an > addition. I think vhost user at least is started at DRIVER_OK and at that point it looks at # of enabled Qs and allocates a bunch of arrays to match. > I'm assuming we need to modify the standard just because it was not > explicitly allowed. To explicitly allow it before DRIVER_OK was not > needed because it was already widespread. > > It would be great for me if we agree the device must support it, but > maybe it is just too late for that. > > Thanks! > > > > E.g. vhost user backends tend to assume no new queues appear after > > > DRIVER_OK. > > > > This backend implementation can be improved without introducing new bits on the guest side. > > Q reset is already a second example that demonstrates that queues will be disabled/enabled after DRIVER_OK. > > > > And for PCI transport, PCI device and driver do not restrict queue_enable access after DRIVER_OK. > > > > 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/ > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]