Re: [virtio-dev] [PATCH v5 08/10] vhost-user: remove the extra PCI capabilities

[Stefan Hajnoczi <stefanha@redhat.com>]

On Fri, Jul 17, 2020 at 06:03:57PM +0300, Nikos Dragazis wrote:
> On 17/7/20 12:48 Î.Î., Stefan Hajnoczi wrote:
> 
> > On Mon, May 18, 2020 at 11:37:19PM +0300, Nikos Dragazis wrote:
> > > -Additional resources are configured on the virtio PCI transport by the following \field{struct virtio_pci_cap.cfg_type} values:
> > > +\subsubsection{Doorbell layout}\label{sec:Device Types / Vhost-user Device Backend / Additional Device Resources / Doorbell layout}
> > > -\begin{lstlisting}
> > > -#define VIRTIO_PCI_CAP_DOORBELL_CFG 6
> > > -#define VIRTIO_PCI_CAP_NOTIFICATION_CFG 7
> > > -#define VIRTIO_PCI_CAP_SHARED_MEMORY_CFG 8
> > > -\end{lstlisting}
> > > +The device MUST reserve 2N+1 virtqueue indices that can be used by the driver to
> > > +send doorbell notifications. The driver can use these indices to send doorbell
> > > +notifications in the same way that it sends available buffer notifications
> > > +\ref{sec:Basic Facilities of a Virtio Device / Notifications} for a virtqueue.
> > Notifications and doorbells should be first-class VIRTIO device model
> > concepts, like Shared Memory resources. It should not be necessary to
> > reserve dummy virtqueues (a hack for getting MSI-X vectors and doorbell
> > registers).
> 
> Well, it's not exactly equivalent to the shared memory resource
> because, in case of doorbells and notifications, the functionality is
> already there. But I see your point. It is a design issue. We could
> definitely standardize the doorbell and notification resources, but I
> don't see why this solution is preferable. Do you have something in
> mind?

Yes, there are advantages to defining doorbells and notifications as
separate concepts:

 * Doorbells and notifications may be implemented differently from
   virtqueue notifications on some the transports.
 * Virtqueues may consume more resources on some transports.
 * Existing drivers may have issues distinguishing between normal
   virtqueues and dummy virtqueues.

Overall I think using dummy virtqueues is a hacky approach. It's
something that would be necessary if we couldn't extend the core VIRTIO
device model. Since we do have the opportunity of extending the core
VIRTIO device model cleanly I think doing so will avoid headaches later.

Stefan

Attachment: signature.asc
Description: PGP signature