OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On 23/7/20 9:29 Ï.Î., Stefan Hajnoczi wrote:

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

OK. Let's standardize them. I will send a separate patch for this. I
can't think of all the details right now, so, I'll come back if anything
troubles me.

Nikos


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]