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? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
