All of lore.kernel.org
 help / color / mirror / Atom feed
* [virtio-comment] [PATCH] virtio-net: (spelling only) support for receive-side scaling
@ 2019-11-25 18:34 Yuri Benditovich
  2019-11-27  9:33 ` Cornelia Huck
  2022-02-20 13:23 ` [virtio-comment] " Michael S. Tsirkin
  0 siblings, 2 replies; 4+ messages in thread
From: Yuri Benditovich @ 2019-11-25 18:34 UTC (permalink / raw)
  To: virtio-comment, mst

Additional patch for previous 'v4 virtio-net: define support for
receive-side scaling' - contains only spelling fixes.

Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
---
 content.tex | 60 ++++++++++++++++++++++++++---------------------------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/content.tex b/content.tex
index 7a7abd2..01be7df 100644
--- a/content.tex
+++ b/content.tex
@@ -2897,11 +2897,11 @@ \subsection{Device configuration layout}\label{sec:Device Types / Network Device
 Three following fields, \field{rss_max_key_size}, \field{rss_max_indirection_table_length}
 and \field{supported_hash_types} only exist if VIRTIO_NET_F_RSS is set.
 
-Field \field{rss_max_key_size} specifies maximal supported length of RSS key in bytes.
+Field \field{rss_max_key_size} specifies the maximal supported length of RSS key in bytes.
 
 Field \field{rss_max_indirection_table_length} specifies maximal number of 16-bit entries in RSS indirection table.
 
-Field \field{supported_hash_types} contains bitmask of supported RSS hash types.
+Field \field{supported_hash_types} contains the bitmask of supported RSS hash types.
 
 Hash types applicable for IPv4 packets:
 \begin{lstlisting}
@@ -2921,7 +2921,7 @@ \subsection{Device configuration layout}\label{sec:Device Types / Network Device
 #define VIRTIO_NET_RSS_HASH_TYPE_TCP_EX            (1 << 7)
 #define VIRTIO_NET_RSS_HASH_TYPE_UDP_EX            (1 << 8)
 \end{lstlisting}
-For exact meaning of VIRTIO_NET_RSS_HASH_TYPE_ flags see \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS hash types}.
+For the exact meaning of VIRTIO_NET_RSS_HASH_TYPE_ flags see \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS hash types}.
 
 \devicenormative{\subsubsection}{Device configuration layout}{Device Types / Network Device / Device configuration layout}
 
@@ -3722,12 +3722,12 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
 
 \paragraph{Device operation in multiqueue mode}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device operation in multiqueue mode}
 
-This specification defines following modes that a device MAY implement for operation with multiple transmit/receive virtqueues:
+This specification defines the following modes that a device MAY implement for operation with multiple transmit/receive virtqueues:
 \begin{itemize}
 \item Automatic receive steering as defined in \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}.
- If a device supports such mode, it offers VIRTIO_NET_F_MQ feature bit.
+ If a device supports this mode, it offers the VIRTIO_NET_F_MQ feature bit.
 \item Receive-side scaling as defined in \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}.
- If a device supports such mode, it offers VIRTIO_NET_F_RSS feature bit.
+ If a device supports this mode, it offers the VIRTIO_NET_F_RSS feature bit.
 \end{itemize}
 
 A device MAY support one of these features or both. The driver MAY negotiate any set of these features that the device supports.
@@ -3741,7 +3741,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
  #define VIRTIO_NET_CTRL_MQ_RSS_CONFIG          1 (for configurable receive steering)
 \end{lstlisting}
 
-If more than one multiqueue mode negotiated, the resulting device configuration is defined by the last command sent by the driver.
+If more than one multiqueue mode is negotiated, the resulting device configuration is defined by the last command sent by the driver.
 
 \paragraph{Automatic receive steering in multiqueue mode}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
 
@@ -3792,7 +3792,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
 
 \devicenormative{\subparagraph}{Automatic receive steering in multiqueue mode}{Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
 
-The device after initialization of reset MUST queue packets only on receiveq1.
+After initialization or reset, the device MUST queue packets only on receiveq1.
 
 The device MUST NOT queue packets on receive queues greater than
 \field{virtqueue_pairs} once it has placed the
@@ -3805,13 +3805,13 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
 (necessarily when not using the legacy interface) little-endian.
 
 \paragraph{Receive-side scaling (RSS)}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS)}
-A device offers feature VIRTIO_NET_F_RSS if it supports RSS receive steering with Toeplitz hash calculation and configurable parameters.
+A device offers the feature VIRTIO_NET_F_RSS if it supports RSS receive steering with Toeplitz hash calculation and configurable parameters.
 
 A driver queries RSS capabilities of the device by reading device configuration as defined in \ref{sec:Device Types / Network Device / Device configuration layout / RSS}
 
 \subparagraph{Setting RSS parameters}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / Setting RSS parameters}
 
-Driver sends VIRTIO_NET_CTRL_MQ_RSS_CONFIG command using following format for \field{command-specific-data}:
+Driver sends a VIRTIO_NET_CTRL_MQ_RSS_CONFIG command using the following format for \field{command-specific-data}:
 \begin{lstlisting}
 struct virtio_net_rss_config {
     le32 hash_types;
@@ -3826,34 +3826,34 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
 Field \field{hash_types} contains a bitmask of allowed hash types as
 defined in \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS hash types}.
 
-Field \field{indirection_table_mask} is a mask to be applied to calculated hash to produce index in \field{indirection_table array}.
+Field \field{indirection_table_mask} is a mask to be applied to the calculated hash to produce an index in \field{indirection_table} array.
 Number of entries in \field{indirection_table} is (\field{indirection_table_mask} + 1).
 
-Field \field{unclassified_queue} contains 0-based index of receive virtqueue to place unclassified packets in. Index 0 corresponds to receiveq1.
+Field \field{unclassified_queue} contains the 0-based index of receive virtqueue to place unclassified packets in. Index 0 corresponds to receiveq1.
 
-Field \field{indirection_table} contains array of 0-based indices of receive virtqueus. Index 0 corresponds to receiveq1.
+Field \field{indirection_table} contains an array of 0-based indices of receive virtqueus. Index 0 corresponds to receiveq1.
 
 A driver sets \field{max_tx_vq} to inform a device how many transmit virtqueues it may use (transmitq1\ldots transmitq \field{max_tx_vq}).
 
 \subparagraph{RSS hash types}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS hash types}
 
-The device calculates hash on IPv4 packets according to the field \field{hash_types} of virtio_net_rss_config structure as follows:
+The device calculates the hash on IPv4 packets according to the field \field{hash_types} of the virtio_net_rss_config structure as follows:
 \begin{itemize}
-\item If VIRTIO_NET_RSS_HASH_TYPE_TCPv4 is set and the packet has TCP header, the hash is calculated over following fields:
+\item If VIRTIO_NET_RSS_HASH_TYPE_TCPv4 is set and the packet has a TCP header, the hash is calculated over the following fields:
 \begin{itemize}
 \item Source IP address
 \item Destination IP address
 \item Source TCP port
 \item Destination TCP port
 \end{itemize}
-\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDPv4 is set and the packet has UDP header, the hash is calculated over following fields:
+\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDPv4 is set and the packet has a UDP header, the hash is calculated over the following fields:
 \begin{itemize}
 \item Source IP address
 \item Destination IP address
 \item Source UDP port
 \item Destination UDP port
 \end{itemize}
-\item Else if VIRTIO_NET_RSS_HASH_TYPE_IPv4 is set, the hash is calculated over following fields:
+\item Else if VIRTIO_NET_RSS_HASH_TYPE_IPv4 is set, the hash is calculated over the following fields:
 \begin{itemize}
 \item Source IP address
 \item Destination IP address
@@ -3861,23 +3861,23 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
 \item Else the device does not calculate the hash
 \end{itemize}
 
-The device calculates hash on IPv6 packets without extension headers according to the field \field{hash_types} of virtio_net_rss_config structure as follows:
+The device calculates the hash on IPv6 packets without extension headers according to the field \field{hash_types} of the virtio_net_rss_config structure as follows:
 \begin{itemize}
-\item If VIRTIO_NET_RSS_HASH_TYPE_TCPv6 is set and the packet has TCPv6 header, the hash is calculated over following fields:
+\item If VIRTIO_NET_RSS_HASH_TYPE_TCPv6 is set and the packet has a TCPv6 header, the hash is calculated over the following fields:
 \begin{itemize}
 \item Source IPv6 address
 \item Destination IPv6 address
 \item Source TCP port
 \item Destination TCP port
 \end{itemize}
-\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDPv6 is set and the packet has UDPv6 header, the hash is calculated over following fields:
+\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDPv6 is set and the packet has a UDPv6 header, the hash is calculated over the following fields:
 \begin{itemize}
 \item Source IPv6 address
 \item Destination IPv6 address
 \item Source UDP port
 \item Destination UDP port
 \end{itemize}
-\item Else if VIRTIO_NET_RSS_HASH_TYPE_IPv6 is set, the hash is calculated over following fields:
+\item Else if VIRTIO_NET_RSS_HASH_TYPE_IPv6 is set, the hash is calculated over the following fields:
 \begin{itemize}
 \item Source IPv6 address
 \item Destination IPv6 address
@@ -3885,23 +3885,23 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
 \item Else the device does not calculate the hash
 \end{itemize}
 
-The device calculates hash on IPv6 packets with extension headers according to the field \field{hash_types} of virtio_net_rss_config structure as follows:
+The device calculates the hash on IPv6 packets with extension headers according to the field \field{hash_types} of the virtio_net_rss_config structure as follows:
 \begin{itemize}
-\item If VIRTIO_NET_RSS_HASH_TYPE_TCP_EX is set and the packet has TCPv6 header, the hash is calculated over following fields:
+\item If VIRTIO_NET_RSS_HASH_TYPE_TCP_EX is set and the packet has a TCPv6 header, the hash is calculated over the following fields:
 \begin{itemize}
 \item Home address from the home address option in the IPv6 destination options header. If the extension header is not present, use the Source IPv6 address.
 \item IPv6 address that is contained in the Routing-Header-Type-2 from the associated extension header. If the extension header is not present, use the Destination IPv6 address.
 \item Source TCP port
 \item Destination TCP port
 \end{itemize}
-\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDP_EX is set and the packet has UDPv6 header, the hash is calculated over following fields:
+\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDP_EX is set and the packet has a UDPv6 header, the hash is calculated over the following fields:
 \begin{itemize}
 \item Home address from the home address option in the IPv6 destination options header. If the extension header is not present, use the Source IPv6 address.
 \item IPv6 address that is contained in the Routing-Header-Type-2 from the associated extension header. If the extension header is not present, use the Destination IPv6 address.
 \item Source UDP port
 \item Destination UDP port
 \end{itemize}
-\item Else if VIRTIO_NET_RSS_HASH_TYPE_IP_EX is set, the hash is calculated over following fields:
+\item Else if VIRTIO_NET_RSS_HASH_TYPE_IP_EX is set, the hash is calculated over the following fields:
 \begin{itemize}
 \item Home address from the home address option in the IPv6 destination options header. If the extension header is not present, use the Source IPv6 address.
 \item IPv6 address that is contained in the Routing-Header-Type-2 from the associated extension header. If the extension header is not present, use the Destination IPv6 address.
@@ -3911,21 +3911,21 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
 
 \drivernormative{\subparagraph}{Setting RSS parameters}{Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) }
 
-A driver MUST NOT send VIRTIO_NET_CTRL_MQ_RSS_CONFIG command if the feature VIRTIO_NET_F_RSS has not been negotiated.
+A driver MUST NOT send the VIRTIO_NET_CTRL_MQ_RSS_CONFIG command if the feature VIRTIO_NET_F_RSS has not been negotiated.
 
 A driver MUST fill \field{indirection_table} array only with indices of enabled queues. Index 0 corresponds to receiveq1.
 
-Number of entries in \field{indirection_table} (\field{indirection_table_mask} + 1) MUST be a power of two.
+The number of entries in \field{indirection_table} (\field{indirection_table_mask} + 1) MUST be a power of two.
 
 A driver MUST use \field{indirection_table_mask} values that are less than \field{rss_max_indirection_table_length} reported by a device.
 
 A driver MUST NOT set any VIRTIO_NET_RSS_HASH_TYPE_ flags that are not supported by a device.
 
 \devicenormative{\subparagraph}{RSS processing}{Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
-The device MUST determine destination queue for network packet as follows:
+The device MUST determine the destination queue for network packets as follows:
 \begin{itemize}
-\item Calculate hash of the packet as defined in \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS hash types}
-\item If the device did not calculate the hash for specific packet, the device directs the packet to the receiveq specified by \field{unclassified_queue} of virtio_net_rss_config structure (value of 0 corresponds to receiveq1).
+\item Calculate the hash of the packet as defined in \ref{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS hash types}
+\item If the device did not calculate the hash for a specific packet, the device directs the packet to the receiveq specified by \field{unclassified_queue} of virtio_net_rss_config structure (value of 0 corresponds to receiveq1).
 \item Apply \field{indirection_table_mask} to the calculated hash and use the result as the index in the indirection table to get 0-based number of destination receiveq (value of 0 corresponds to receiveq1).
 \end{itemize}
 
-- 
2.17.2


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/


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [virtio-comment] [PATCH] virtio-net: (spelling only) support for receive-side scaling
  2019-11-25 18:34 [virtio-comment] [PATCH] virtio-net: (spelling only) support for receive-side scaling Yuri Benditovich
@ 2019-11-27  9:33 ` Cornelia Huck
  2022-02-20 13:23 ` [virtio-comment] " Michael S. Tsirkin
  1 sibling, 0 replies; 4+ messages in thread
From: Cornelia Huck @ 2019-11-27  9:33 UTC (permalink / raw)
  To: Yuri Benditovich; +Cc: virtio-comment, mst

On Mon, 25 Nov 2019 20:34:30 +0200
Yuri Benditovich <yuri.benditovich@daynix.com> wrote:

> Additional patch for previous 'v4 virtio-net: define support for
> receive-side scaling' - contains only spelling fixes.
> 
> Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
> ---
>  content.tex | 60 ++++++++++++++++++++++++++---------------------------
>  1 file changed, 30 insertions(+), 30 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>


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/


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [virtio-comment] Re: [PATCH] virtio-net: (spelling only) support for receive-side scaling
  2019-11-25 18:34 [virtio-comment] [PATCH] virtio-net: (spelling only) support for receive-side scaling Yuri Benditovich
  2019-11-27  9:33 ` Cornelia Huck
@ 2022-02-20 13:23 ` Michael S. Tsirkin
  2022-02-22 10:24   ` Yuri Benditovich
  1 sibling, 1 reply; 4+ messages in thread
From: Michael S. Tsirkin @ 2022-02-20 13:23 UTC (permalink / raw)
  To: Yuri Benditovich; +Cc: virtio-comment

On Mon, Nov 25, 2019 at 08:34:30PM +0200, Yuri Benditovich wrote:
> Additional patch for previous 'v4 virtio-net: define support for
> receive-side scaling' - contains only spelling fixes.
> 
> Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>

I just noticed that description of Device Initialization has not been
updated with this patch.

For example:

\item Identify and initialize the receive and
  transmission virtqueues, up to N of each kind. If
  VIRTIO_NET_F_MQ feature bit is negotiated,
  N=\field{max_virtqueue_pairs}, otherwise identify N=1.

\item If the VIRTIO_NET_F_CTRL_VQ feature bit is negotiated,
  identify the control virtqueue.

\item Fill the receive queues with buffers: see \ref{sec:Device Types / Network Device / Device Operation / Setting Up Receive Buffers}.

\item Even with VIRTIO_NET_F_MQ, only receiveq1, transmitq1 and
  controlq are used by default.  The driver would send the
  VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command specifying the
  number of the transmit and receive queues to use.


there are some more instances of this.

I created https://github.com/oasis-tcs/virtio-spec/issues/135
to track this.
Also, https://github.com/oasis-tcs/virtio-spec/issues/134 since
VIRTIO_NET_F_MQ name is now confusing.


Yuri, could you try to address these?

Thanks!

-- 
MST


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/


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [virtio-comment] Re: [PATCH] virtio-net: (spelling only) support for receive-side scaling
  2022-02-20 13:23 ` [virtio-comment] " Michael S. Tsirkin
@ 2022-02-22 10:24   ` Yuri Benditovich
  0 siblings, 0 replies; 4+ messages in thread
From: Yuri Benditovich @ 2022-02-22 10:24 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: virtio-comment

On Sun, Feb 20, 2022 at 3:23 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, Nov 25, 2019 at 08:34:30PM +0200, Yuri Benditovich wrote:
> > Additional patch for previous 'v4 virtio-net: define support for
> > receive-side scaling' - contains only spelling fixes.
> >
> > Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
>
> I just noticed that description of Device Initialization has not been
> updated with this patch.
>
> For example:
>
> \item Identify and initialize the receive and
>   transmission virtqueues, up to N of each kind. If
>   VIRTIO_NET_F_MQ feature bit is negotiated,
>   N=\field{max_virtqueue_pairs}, otherwise identify N=1.
>
> \item If the VIRTIO_NET_F_CTRL_VQ feature bit is negotiated,
>   identify the control virtqueue.
>
> \item Fill the receive queues with buffers: see \ref{sec:Device Types / Network Device / Device Operation / Setting Up Receive Buffers}.
>
> \item Even with VIRTIO_NET_F_MQ, only receiveq1, transmitq1 and
>   controlq are used by default.  The driver would send the
>   VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command specifying the
>   number of the transmit and receive queues to use.
>
>
> there are some more instances of this.
>
> I created https://github.com/oasis-tcs/virtio-spec/issues/135
> to track this.
> Also, https://github.com/oasis-tcs/virtio-spec/issues/134 since
> VIRTIO_NET_F_MQ name is now confusing.
>
>
> Yuri, could you try to address these?

Yes, I will do that

>
> Thanks!
>
> --
> MST
>

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/


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-02-22 10:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25 18:34 [virtio-comment] [PATCH] virtio-net: (spelling only) support for receive-side scaling Yuri Benditovich
2019-11-27  9:33 ` Cornelia Huck
2022-02-20 13:23 ` [virtio-comment] " Michael S. Tsirkin
2022-02-22 10:24   ` Yuri Benditovich

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.