All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: mst@redhat.com, virtio-comment@lists.oasis-open.org,
	eperezma@redhat.com, lulu@redhat.com, rob.miller@broadcom.com,
	stefanha@redhat.com, pasic@linux.ibm.com, sgarzare@redhat.com
Subject: Re: [virtio-comment] Re: [PATCH] virtio-pci: introduce VIRITO_F_QUEUE_STATE
Date: Wed, 17 Mar 2021 13:57:40 +0100	[thread overview]
Message-ID: <20210317135740.6a3383b3.cohuck@redhat.com> (raw)
In-Reply-To: <94ca35e8-0353-59bd-b753-cf2e549d89de@redhat.com>

On Wed, 17 Mar 2021 11:43:53 +0800
Jason Wang <jasowang@redhat.com> wrote:

> 在 2021/3/16 下午7:06, Cornelia Huck 写道:
> > On Tue, 16 Mar 2021 10:53:37 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >  
> >> 在 2021/3/15 下午11:24, Cornelia Huck 写道:  
> >>> On Mon, 15 Mar 2021 10:58:46 +0800
> >>> Jason Wang <jasowang@redhat.com> wrote:

> >>>>    \drivernormative{\paragraph}{Common configuration structure layout}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout}
> >>>>    
> >>>>    The driver MUST NOT write to \field{device_feature}, \field{num_queues}, \field{config_generation}, \field{queue_notify_off} or \field{queue_notify_data}.
> >>>> @@ -981,6 +1009,13 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
> >>>>    
> >>>>    The driver MUST NOT write a 0 to \field{queue_enable}.
> >>>>    
> >>>> +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver SHOULD set the
> >>>> +state of each virtqueue through \field{queue_state} before setting the
> >>>> +DRIVER_OK \field{device status} bit and SHOULD NOT write to
> >>>> +\field{queue_state} after setting the DRIVER_OK \field{device status}
> >>>> +bit. If a driver want to get the virtqueue state, it MUST first reset
> >>>> +the device then read state from \field{queue_state}.  
> >>> What should the driver do with a 'fresh' device? Does it need to start
> >>> out with a reset, read the (zero) state, and then write it back?  
> >>
> >> If 'fresh' means a normal probe procedure, in this case we don't need to
> >> get the virtqueue state. What we need is to set a proper state.  For
> >> split virtqueue, the driver should write 0 (as last_avail_idx). For
> >> packed virtqueue, the driver shoudl write:
> >>
> >> {.last_avail_idx = 0, .last_avail_wrap_counter=1, .used_idx=0,
> >> used_wrap_counter=1}.  
> > Yes, that was what I had been thinking of.
> >
> > So, I think the driver won't get a useful state if it reads the state
> > after reset for a previously unused device (the device statement only
> > says that it MUST NOT clear the state after reset)?  
> 
> 
> Yes.
> 
> 
> > Do we need to add a
> > sentence that a driver needs to do that initial setup of the state for
> > a device it has not used previously?  
> 
> 
> I'm not sure whether we need to treat the device which has not been used 
> separatedly. Technically, when VIRTIO_F_QUEUE_STATE is neogitated, 
> driver can teach the device to start from non 0 index (though it was not 
> the way how Linux did right now).

Basically, the driver needs to be aware that there simply will not be
any usable state, and it needs to skip the getting and instead set some
initial values it deems reasonable. If that's obvious, I don't think we
need to spell it out.


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/


      reply	other threads:[~2021-03-17 12:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15  2:58 [virtio-comment] [PATCH] virtio-pci: introduce VIRITO_F_QUEUE_STATE Jason Wang
2021-03-15 12:24 ` [virtio-comment] " Eugenio Perez Martin
2021-03-16  6:08   ` Jason Wang
2021-03-16  7:37     ` Eugenio Perez Martin
2021-03-15 15:24 ` Cornelia Huck
2021-03-16  2:53   ` Jason Wang
2021-03-16 11:06     ` Cornelia Huck
2021-03-17  3:43       ` Jason Wang
2021-03-17 12:57         ` Cornelia Huck [this message]

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=20210317135740.6a3383b3.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=lulu@redhat.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=rob.miller@broadcom.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    /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.