virtio — archive

[Michael S. Tsirkin <mst@redhat.com>]

On Fri, Aug 19, 2022 at 08:28:41AM +0800, Jason Wang wrote: > On Thu, Aug 18, 2022 at 4:55 PM Max Gurtovoy <mgurtovoy@nvidia.com> wrote: > > > > > > On 8/18/2022 11:49 AM, Jason Wang wrote: > > > On Sat, Aug 13, 2022 at 1:19 AM Michael S. Tsirkin <mst@redhat.com> wrote: > > >> From: Max Gurtovoy <mgurtovoy@nvidia.com> > > >> > > >> This new register will be used for querying the index of the admin > > >> virtqueue of a virtio device. To configure, reset or enable the admin > > >> virtqueue, the driver should follow existing queue configuration/setup > > >> sequence. > > >> > > >> Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> > > >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > >> --- > > >> content.tex 14 ++++++++++++++ > > >> 1 file changed, 14 insertions(+) > > >> > > >> diff --git a/content.tex b/content.tex > > >> index 6ce1c07..297cb4a 100644 > > >> --- a/content.tex > > >> +++ b/content.tex > > >> @@ -904,6 +904,9 @@ subsubsection{Common configuration structure layout}label{sec:Virtio Transport > > >> le64 queue_device; /* read-write */ > > >> le16 queue_notify_data; /* read-only for driver */ > > >> le16 queue_reset; /* read-write */ > > >> + > > >> + /* About the administration virtqueue. */ > > >> + le16 admin_queue_index; /* read-only for driver */ > > > Is there a chance that we may have multiple admin virtqueues? > > > > No, same as we probably can't have multiple ctrl virtqueues.. > > For control virtqueue, it's technically possible but doesn't have too > much value. > > But for admin virtqueue we can: > > admin vq 1: group 1 > admin vq 2: group 2 > > ? > > Thanks I don't see how *that* will solve scalability issues, e.g. a group might have 10k devices. Just allowing submitting commands to any of multiple admin vqs might make sense. I'm looking for a clean interface to expose that though and don't see it yet. > > > > > > > > > > Thanks > > > > > > > > >> }; > > >> end{lstlisting} > > >> > > >> @@ -989,6 +992,10 @@ subsubsection{Common configuration structure layout}label{sec:Virtio Transport > > >> This field exists only if VIRTIO_F_RING_RESET has been > > >> negotiated. (see ef{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}). > > >> > > >> +item[field{admin_queue_index}] > > >> + The device uses this to report the index of the administration virtqueue. > > >> + This field is valid only if VIRTIO_F_ADMIN_VQ has been negotiated. > > >> + > > >> end{description} > > >> > > >> devicenormative{paragraph}{Common configuration structure layout}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout} > > >> @@ -1075,6 +1082,9 @@ subsubsection{Common configuration structure layout}label{sec:Virtio Transport > > >> were used before the queue reset. > > >> (see ef{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}). > > >> > > >> +If VIRTIO_F_ADMIN_VQ has been negotiated, the driver MUST > > >> +configure the administration virtqueue using the value of field{admin_queue_index}. > > >> + > > >> subsubsection{Notification structure layout}label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Notification capability} > > >> > > >> The notification location is found using the VIRTIO_PCI_CAP_NOTIFY_CFG > > >> @@ -6947,6 +6957,10 @@ chapter{Reserved Feature Bits}label{sec:Reserved Feature Bits} > > >> See ef{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}. > > >> > > >> item[VIRTIO_F_ADMIN_VQ (41)] This feature indicates that an administration virtqueue is supported. > > >> + At the moment this feature is only supported for devices using > > >> + ef{sec:Virtio Transport Options / Virtio Over PCI > > >> + Bus}~ ameref{sec:Virtio Transport Options / Virtio Over PCI Bus} > > >> + as the transport. > > >> > > >> end{description} > > >> > > >> -- > > >> MST > > >> > >