* [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE @ 2021-03-22 3:47 Jason Wang 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility Jason Wang ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Jason Wang @ 2021-03-22 3:47 UTC (permalink / raw) To: mst, virtio-comment Cc: eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford, Jason Wang Hi All: This is a new version to support VIRTIO_F_QUEUE_STATE. The feautre extends the basic facility to allow the driver to set and get device internal virtqueue state. This main motivation is to support live migration of virtio devices. Please review. Changes since V1: - Introduce a dedicated part in the basic facility to describe the virtqueue state. - Split the state into avail state and used state, use two le16 isntead of a single u64 in the PCI implementation. Thanks Jason Wang (2): virtio: introduce virtqueue state as basic facility virtio-pci: implement VIRTIO_F_QUEUE_STATE content.tex | 93 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) -- 2.24.3 (Apple Git-128) 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] 19+ messages in thread
* [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-22 3:47 [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Jason Wang @ 2021-03-22 3:47 ` Jason Wang 2021-03-22 8:19 ` [virtio-comment] " Eugenio Perez Martin 2021-03-23 10:27 ` [virtio-comment] " Stefan Hajnoczi 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 2/2] virtio-pci: implement VIRTIO_F_QUEUE_STATE Jason Wang 2021-03-23 10:40 ` [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Stefan Hajnoczi 2 siblings, 2 replies; 19+ messages in thread From: Jason Wang @ 2021-03-22 3:47 UTC (permalink / raw) To: mst, virtio-comment Cc: eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford, Jason Wang This patch adds new device facility to save and restore virtqueue state. The virtqueue state is split into two parts: - The available state: The state that is used for read the next available buffer. - The used state: The state that is used for make buffer used. This will simply the transport specific method implemention. E.g two le16 could be used instead of a single le32). For split virtqueue, we only need the available state since the used state is implemented in the virtqueue itself (the used index). For packed virtqueue, we need both the available state and the used state. Those states are required to implement live migration support for virtio device. Signed-off-by: Jason Wang <jasowang@redhat.com> --- content.tex | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/content.tex b/content.tex index 620c0e2..af39111 100644 --- a/content.tex +++ b/content.tex @@ -385,6 +385,83 @@ \section{Exporting Objects}\label{sec:Basic Facilities of a Virtio Device / Expo types. It is RECOMMENDED that devices generate version 4 UUIDs as specified by \hyperref[intro:rfc4122]{[RFC4122]}. +\section{Virtqueue State}\label{sec:Virtqueues / Virtqueue State} + +When VIRTIO_F_QUEUE_STATE is negotiated, the driver can set and +get the device internal virtqueue state through the following +fields. The way to access those fields is transport specific. + +\subsection{\field{Available State} Field} + +The availabe state field is two bytes virtqueue state that is used by +the device to read for the next available buffer. + +When VIRTIO_RING_F_PACKED is not negotiated, it contains: + +\begin{lstlisting} +le16 last_avail_idx; +\end{lstlisting} + +The \field{last_avail_idx} field is the location where the device read +for the next index from the virtqueue available ring. + +When VIRTIO_RING_F_PACKED is negotiated, it contains: + +\begin{lstlisting} +le16 { + last_avail_idx : 15; + last_avail_wrap_counter : 1; +}; +\end{lstlisting} + +The \field{last_avail_idx} field is the location where the device read +for the next descriptor from the virtqueue descriptor ring. + +The \field{last_avail_wrap_counter} field is the last driver ring wrap +counter that is observed by the device. + +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. + +\subsection{\field{Used State} Field} + +The availabe state field is two bytes virtqueue state that is used by +the device to make buffer used. + +When VIRTIO_RING_F_PACKED is negotiated, the used state contains: + +\begin{lstlisting} +le16 { + used_idx : 15; + used_wrap_counter : 1; +}; +\end{lstlisting} + +The \field{used_idx} field is the location where the device write next +used descriptor to the descriptor ring. + +The \field{used_wrap_counter} field is the wrap counter that is used +by the device. + +The used state is unnecessary when VIRTIO_RING_F_PACKED is not +negotiated. + +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. + +\drivernormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} + +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver MUST set the +state of each virtqueue after setting the FEATURE_OK status bit but +before setting the DRIVER_OK status bit. + +If VIRTIO_F_QUEUE_STATE has been negotiated. a driver MUST reset the +device before getting the virtqueue state. + +\devicenormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} + +If VIRTIO_F_QUEUE_STATE has been negotiated, a device MUST NOT clear +the queue state upon reset and MUST reset the queue state when the +driver sets ACKNOWLEDGE status bit. + \chapter{General Initialization And Device Operation}\label{sec:General Initialization And Device Operation} We start with an overview of device initialization, then expand on the @@ -6596,6 +6673,10 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits} transport specific. For more details about driver notifications over PCI see \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Available Buffer Notifications}. +\item[VIRTIO_F_QUEUE_STATE(40)] This feature indicates that the driver + can set and get the virtqueue state. + See \ref{sec:Virtqueues / Virtqueue State}~\nameref{sec:Virtqueues / Virtqueue State}. + \end{description} \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits} -- 2.24.3 (Apple Git-128) 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] 19+ messages in thread
* [virtio-comment] Re: [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility Jason Wang @ 2021-03-22 8:19 ` Eugenio Perez Martin 2021-03-23 2:54 ` Jason Wang 2021-03-23 10:27 ` [virtio-comment] " Stefan Hajnoczi 1 sibling, 1 reply; 19+ messages in thread From: Eugenio Perez Martin @ 2021-03-22 8:19 UTC (permalink / raw) To: Jason Wang Cc: Michael Tsirkin, virtio-comment, Cindy Lu, Rob Miller, Halil Pasic, Stefano Garzarella, Cornelia Huck, Jim Harford On Mon, Mar 22, 2021 at 4:47 AM Jason Wang <jasowang@redhat.com> wrote: > > This patch adds new device facility to save and restore virtqueue > state. The virtqueue state is split into two parts: > > - The available state: The state that is used for read the next > available buffer. > - The used state: The state that is used for make buffer used. > > This will simply the transport specific method implemention. E.g two > le16 could be used instead of a single le32). For split virtqueue, we > only need the available state since the used state is implemented in > the virtqueue itself (the used index). > For packed virtqueue, we need > both the available state and the used state. > > Those states are required to implement live migration support for > virtio device. > > Signed-off-by: Jason Wang <jasowang@redhat.com> > --- > content.tex | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 81 insertions(+) > > diff --git a/content.tex b/content.tex > index 620c0e2..af39111 100644 > --- a/content.tex > +++ b/content.tex > @@ -385,6 +385,83 @@ \section{Exporting Objects}\label{sec:Basic Facilities of a Virtio Device / Expo > types. It is RECOMMENDED that devices generate version 4 > UUIDs as specified by \hyperref[intro:rfc4122]{[RFC4122]}. > > +\section{Virtqueue State}\label{sec:Virtqueues / Virtqueue State} > + > +When VIRTIO_F_QUEUE_STATE is negotiated, the driver can set and > +get the device internal virtqueue state through the following > +fields. The way to access those fields is transport specific. > + > +\subsection{\field{Available State} Field} > + > +The availabe state field is two bytes virtqueue state that is used by > +the device to read for the next available buffer. > + > +When VIRTIO_RING_F_PACKED is not negotiated, it contains: > + > +\begin{lstlisting} > +le16 last_avail_idx; > +\end{lstlisting} > + > +The \field{last_avail_idx} field is the location where the device read > +for the next index from the virtqueue available ring. > + > +When VIRTIO_RING_F_PACKED is negotiated, it contains: > + > +\begin{lstlisting} > +le16 { > + last_avail_idx : 15; > + last_avail_wrap_counter : 1; > +}; > +\end{lstlisting} > + > +The \field{last_avail_idx} field is the location where the device read > +for the next descriptor from the virtqueue descriptor ring. > + > +The \field{last_avail_wrap_counter} field is the last driver ring wrap > +counter that is observed by the device. > + > +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. > + > +\subsection{\field{Used State} Field} > + > +The availabe state field is two bytes virtqueue state that is used by > +the device to make buffer used. > + > +When VIRTIO_RING_F_PACKED is negotiated, the used state contains: > + > +\begin{lstlisting} > +le16 { > + used_idx : 15; > + used_wrap_counter : 1; > +}; > +\end{lstlisting} > + > +The \field{used_idx} field is the location where the device write next > +used descriptor to the descriptor ring. > + > +The \field{used_wrap_counter} field is the wrap counter that is used > +by the device. > + > +The used state is unnecessary when VIRTIO_RING_F_PACKED is not > +negotiated. Maybe we could be more specific with "unnecessary"? Either to say: 1) "For split virtqueue the device/driver must ignore this field at start/recover state and use used_idx in the used ring.", so use of this field is totally unspecified. 2) "For split virtqueue, the device/driver must prefer to get/set state from virtqueue's used ring in case of discrepancy with this value". I prefer the former so there is only one place to set/retrieve it, but something like this would avoid confusion in my opinion. I find it equally convenient to prefer the virtqueue memory or the transport-specific used state field, though. > + > +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. > + > +\drivernormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} > + > +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver MUST set the > +state of each virtqueue after setting the FEATURE_OK status bit but > +before setting the DRIVER_OK status bit. > + > +If VIRTIO_F_QUEUE_STATE has been negotiated. a driver MUST reset the > +device before getting the virtqueue state. > + > +\devicenormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} > + > +If VIRTIO_F_QUEUE_STATE has been negotiated, a device MUST NOT clear > +the queue state upon reset and MUST reset the queue state when the > +driver sets ACKNOWLEDGE status bit. > + > \chapter{General Initialization And Device Operation}\label{sec:General Initialization And Device Operation} > > We start with an overview of device initialization, then expand on the > @@ -6596,6 +6673,10 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits} > transport specific. > For more details about driver notifications over PCI see \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Available Buffer Notifications}. > > +\item[VIRTIO_F_QUEUE_STATE(40)] This feature indicates that the driver > + can set and get the virtqueue state. > + See \ref{sec:Virtqueues / Virtqueue State}~\nameref{sec:Virtqueues / Virtqueue State}. > + > \end{description} > > \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits} > -- > 2.24.3 (Apple Git-128) > 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] 19+ messages in thread
* Re: [virtio-comment] Re: [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-22 8:19 ` [virtio-comment] " Eugenio Perez Martin @ 2021-03-23 2:54 ` Jason Wang 2021-03-23 9:27 ` Eugenio Perez Martin 0 siblings, 1 reply; 19+ messages in thread From: Jason Wang @ 2021-03-23 2:54 UTC (permalink / raw) To: virtio-comment 在 2021/3/22 下午4:19, Eugenio Perez Martin 写道: > On Mon, Mar 22, 2021 at 4:47 AM Jason Wang <jasowang@redhat.com> wrote: >> This patch adds new device facility to save and restore virtqueue >> state. The virtqueue state is split into two parts: >> >> - The available state: The state that is used for read the next >> available buffer. >> - The used state: The state that is used for make buffer used. >> >> This will simply the transport specific method implemention. E.g two >> le16 could be used instead of a single le32). For split virtqueue, we >> only need the available state since the used state is implemented in >> the virtqueue itself (the used index). >> For packed virtqueue, we need >> both the available state and the used state. >> >> Those states are required to implement live migration support for >> virtio device. >> >> Signed-off-by: Jason Wang <jasowang@redhat.com> >> --- >> content.tex | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 81 insertions(+) >> >> diff --git a/content.tex b/content.tex >> index 620c0e2..af39111 100644 >> --- a/content.tex >> +++ b/content.tex >> @@ -385,6 +385,83 @@ \section{Exporting Objects}\label{sec:Basic Facilities of a Virtio Device / Expo >> types. It is RECOMMENDED that devices generate version 4 >> UUIDs as specified by \hyperref[intro:rfc4122]{[RFC4122]}. >> >> +\section{Virtqueue State}\label{sec:Virtqueues / Virtqueue State} >> + >> +When VIRTIO_F_QUEUE_STATE is negotiated, the driver can set and >> +get the device internal virtqueue state through the following >> +fields. The way to access those fields is transport specific. >> + >> +\subsection{\field{Available State} Field} >> + >> +The availabe state field is two bytes virtqueue state that is used by >> +the device to read for the next available buffer. >> + >> +When VIRTIO_RING_F_PACKED is not negotiated, it contains: >> + >> +\begin{lstlisting} >> +le16 last_avail_idx; >> +\end{lstlisting} >> + >> +The \field{last_avail_idx} field is the location where the device read >> +for the next index from the virtqueue available ring. >> + >> +When VIRTIO_RING_F_PACKED is negotiated, it contains: >> + >> +\begin{lstlisting} >> +le16 { >> + last_avail_idx : 15; >> + last_avail_wrap_counter : 1; >> +}; >> +\end{lstlisting} >> + >> +The \field{last_avail_idx} field is the location where the device read >> +for the next descriptor from the virtqueue descriptor ring. >> + >> +The \field{last_avail_wrap_counter} field is the last driver ring wrap >> +counter that is observed by the device. >> + >> +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. >> + >> +\subsection{\field{Used State} Field} >> + >> +The availabe state field is two bytes virtqueue state that is used by >> +the device to make buffer used. >> + >> +When VIRTIO_RING_F_PACKED is negotiated, the used state contains: >> + >> +\begin{lstlisting} >> +le16 { >> + used_idx : 15; >> + used_wrap_counter : 1; >> +}; >> +\end{lstlisting} >> + >> +The \field{used_idx} field is the location where the device write next >> +used descriptor to the descriptor ring. >> + >> +The \field{used_wrap_counter} field is the wrap counter that is used >> +by the device. >> + >> +The used state is unnecessary when VIRTIO_RING_F_PACKED is not >> +negotiated. > Maybe we could be more specific with "unnecessary"? Either to say: > 1) "For split virtqueue the device/driver must ignore this field at > start/recover state and use used_idx in the used ring.", so use of > this field is totally unspecified. RIght, this could be added as normative part. An interesting part is the timing of the read, the current semantics depends on reset command to stop the device (to avoid introduing new status). So in order to get the state, driver needs: 1) reset the device 2) read the avail and used states Technically, after step 1, driver doesn't know whether nor not it's a split virtqueue. For write, it should be fine since we mandate it can only be done after FEATURE_OK so driver know it's a split or not. So how about something like in the driver normative: To get the virtqueue state, the driver MUST remember the queue format that is used and read the virtqueue state accordingly after resetting the device. E.g if the split virtqueue is used before resetting the device, the driver MUST NOT acces used state after restting the device. To write the virtqueue state, the driver MUST NOT write to the used state if VIRTIO_F_RING_PACKED is not negotiated. Thanks > 2) "For split virtqueue, the device/driver must prefer to get/set > state from virtqueue's used ring in case of discrepancy with this > value". > > I prefer the former so there is only one place to set/retrieve it, but > something like this would avoid confusion in my opinion. I find it > equally convenient to prefer the virtqueue memory or the > transport-specific used state field, though. 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] 19+ messages in thread
* Re: [virtio-comment] Re: [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-23 2:54 ` Jason Wang @ 2021-03-23 9:27 ` Eugenio Perez Martin 0 siblings, 0 replies; 19+ messages in thread From: Eugenio Perez Martin @ 2021-03-23 9:27 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment On Tue, Mar 23, 2021 at 3:54 AM Jason Wang <jasowang@redhat.com> wrote: > > > 在 2021/3/22 下午4:19, Eugenio Perez Martin 写道: > > On Mon, Mar 22, 2021 at 4:47 AM Jason Wang <jasowang@redhat.com> wrote: > >> This patch adds new device facility to save and restore virtqueue > >> state. The virtqueue state is split into two parts: > >> > >> - The available state: The state that is used for read the next > >> available buffer. > >> - The used state: The state that is used for make buffer used. > >> > >> This will simply the transport specific method implemention. E.g two > >> le16 could be used instead of a single le32). For split virtqueue, we > >> only need the available state since the used state is implemented in > >> the virtqueue itself (the used index). > >> For packed virtqueue, we need > >> both the available state and the used state. > >> > >> Those states are required to implement live migration support for > >> virtio device. > >> > >> Signed-off-by: Jason Wang <jasowang@redhat.com> > >> --- > >> content.tex | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 81 insertions(+) > >> > >> diff --git a/content.tex b/content.tex > >> index 620c0e2..af39111 100644 > >> --- a/content.tex > >> +++ b/content.tex > >> @@ -385,6 +385,83 @@ \section{Exporting Objects}\label{sec:Basic Facilities of a Virtio Device / Expo > >> types. It is RECOMMENDED that devices generate version 4 > >> UUIDs as specified by \hyperref[intro:rfc4122]{[RFC4122]}. > >> > >> +\section{Virtqueue State}\label{sec:Virtqueues / Virtqueue State} > >> + > >> +When VIRTIO_F_QUEUE_STATE is negotiated, the driver can set and > >> +get the device internal virtqueue state through the following > >> +fields. The way to access those fields is transport specific. > >> + > >> +\subsection{\field{Available State} Field} > >> + > >> +The availabe state field is two bytes virtqueue state that is used by > >> +the device to read for the next available buffer. > >> + > >> +When VIRTIO_RING_F_PACKED is not negotiated, it contains: > >> + > >> +\begin{lstlisting} > >> +le16 last_avail_idx; > >> +\end{lstlisting} > >> + > >> +The \field{last_avail_idx} field is the location where the device read > >> +for the next index from the virtqueue available ring. > >> + > >> +When VIRTIO_RING_F_PACKED is negotiated, it contains: > >> + > >> +\begin{lstlisting} > >> +le16 { > >> + last_avail_idx : 15; > >> + last_avail_wrap_counter : 1; > >> +}; > >> +\end{lstlisting} > >> + > >> +The \field{last_avail_idx} field is the location where the device read > >> +for the next descriptor from the virtqueue descriptor ring. > >> + > >> +The \field{last_avail_wrap_counter} field is the last driver ring wrap > >> +counter that is observed by the device. > >> + > >> +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. > >> + > >> +\subsection{\field{Used State} Field} > >> + > >> +The availabe state field is two bytes virtqueue state that is used by > >> +the device to make buffer used. > >> + > >> +When VIRTIO_RING_F_PACKED is negotiated, the used state contains: > >> + > >> +\begin{lstlisting} > >> +le16 { > >> + used_idx : 15; > >> + used_wrap_counter : 1; > >> +}; > >> +\end{lstlisting} > >> + > >> +The \field{used_idx} field is the location where the device write next > >> +used descriptor to the descriptor ring. > >> + > >> +The \field{used_wrap_counter} field is the wrap counter that is used > >> +by the device. > >> + > >> +The used state is unnecessary when VIRTIO_RING_F_PACKED is not > >> +negotiated. > > Maybe we could be more specific with "unnecessary"? Either to say: > > 1) "For split virtqueue the device/driver must ignore this field at > > start/recover state and use used_idx in the used ring.", so use of > > this field is totally unspecified. > > > RIght, this could be added as normative part. > > An interesting part is the timing of the read, the current semantics > depends on reset command to stop the device (to avoid introduing new > status). > > So in order to get the state, driver needs: > > 1) reset the device > 2) read the avail and used states > > Technically, after step 1, driver doesn't know whether nor not it's a > split virtqueue. > > For write, it should be fine since we mandate it can only be done after > FEATURE_OK so driver know it's a split or not. > > So how about something like in the driver normative: > > To get the virtqueue state, the driver MUST remember the queue format > that is used and read the virtqueue state accordingly after resetting > the device. E.g if the split virtqueue is used before resetting the > device, the driver MUST NOT acces used state after restting the device. > > To write the virtqueue state, the driver MUST NOT write to the used > state if VIRTIO_F_RING_PACKED is not negotiated. > Right, I'm not sure if it will have a use case in the future but I find it better to explicitly state that. Thanks! > Thanks > > > > 2) "For split virtqueue, the device/driver must prefer to get/set > > state from virtqueue's used ring in case of discrepancy with this > > value". > > > > I prefer the former so there is only one place to set/retrieve it, but > > something like this would avoid confusion in my opinion. I find it > > equally convenient to prefer the virtqueue memory or the > > transport-specific used state field, though. > > > 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/ > 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] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility Jason Wang 2021-03-22 8:19 ` [virtio-comment] " Eugenio Perez Martin @ 2021-03-23 10:27 ` Stefan Hajnoczi 2021-03-24 8:15 ` Jason Wang 1 sibling, 1 reply; 19+ messages in thread From: Stefan Hajnoczi @ 2021-03-23 10:27 UTC (permalink / raw) To: Jason Wang Cc: mst, virtio-comment, eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford [-- Attachment #1: Type: text/plain, Size: 5300 bytes --] On Mon, Mar 22, 2021 at 11:47:16AM +0800, Jason Wang wrote: > This patch adds new device facility to save and restore virtqueue > state. The virtqueue state is split into two parts: > > - The available state: The state that is used for read the next > available buffer. > - The used state: The state that is used for make buffer used. > > This will simply the transport specific method implemention. E.g two > le16 could be used instead of a single le32). For split virtqueue, we > only need the available state since the used state is implemented in > the virtqueue itself (the used index). For packed virtqueue, we need > both the available state and the used state. > > Those states are required to implement live migration support for > virtio device. > > Signed-off-by: Jason Wang <jasowang@redhat.com> > --- > content.tex | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 81 insertions(+) > > diff --git a/content.tex b/content.tex > index 620c0e2..af39111 100644 > --- a/content.tex > +++ b/content.tex > @@ -385,6 +385,83 @@ \section{Exporting Objects}\label{sec:Basic Facilities of a Virtio Device / Expo > types. It is RECOMMENDED that devices generate version 4 > UUIDs as specified by \hyperref[intro:rfc4122]{[RFC4122]}. > > +\section{Virtqueue State}\label{sec:Virtqueues / Virtqueue State} > + > +When VIRTIO_F_QUEUE_STATE is negotiated, the driver can set and > +get the device internal virtqueue state through the following > +fields. The way to access those fields is transport specific. > + > +\subsection{\field{Available State} Field} > + > +The availabe state field is two bytes virtqueue state that is used by s/availabe/available/ s/bytes virtqueue state/bytes of virtqueue state/ > +the device to read for the next available buffer. > + > +When VIRTIO_RING_F_PACKED is not negotiated, it contains: > + > +\begin{lstlisting} > +le16 last_avail_idx; > +\end{lstlisting} > + > +The \field{last_avail_idx} field is the location where the device read > +for the next index from the virtqueue available ring. Perhaps this field can be defined in more detail: The \field{last_avail_idx} field is the free-running available ring index where the device will read the next available head of a descriptor chain. See also \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Available Ring}. > + > +When VIRTIO_RING_F_PACKED is negotiated, it contains: > + > +\begin{lstlisting} > +le16 { > + last_avail_idx : 15; > + last_avail_wrap_counter : 1; > +}; > +\end{lstlisting} > + > +The \field{last_avail_idx} field is the location where the device read > +for the next descriptor from the virtqueue descriptor ring. Similar wording as above can be used. > + > +The \field{last_avail_wrap_counter} field is the last driver ring wrap > +counter that is observed by the device. s/is/was/? > + > +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. > + > +\subsection{\field{Used State} Field} > + > +The availabe state field is two bytes virtqueue state that is used by s/availabe/used/ s/bytes virtqueue state/bytes of virtqueue state/ > +the device to make buffer used. s/to make buffer used/when marking a buffer used/ > + > +When VIRTIO_RING_F_PACKED is negotiated, the used state contains: > + > +\begin{lstlisting} > +le16 { > + used_idx : 15; > + used_wrap_counter : 1; > +}; > +\end{lstlisting} > + > +The \field{used_idx} field is the location where the device write next > +used descriptor to the descriptor ring. Similar as above. It should at least mention whether this is a free-running index or always less than queue size. > + > +The \field{used_wrap_counter} field is the wrap counter that is used > +by the device. > + > +The used state is unnecessary when VIRTIO_RING_F_PACKED is not > +negotiated. > + > +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. > + > +\drivernormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} > + > +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver MUST set the > +state of each virtqueue after setting the FEATURE_OK status bit but > +before setting the DRIVER_OK status bit. > + > +If VIRTIO_F_QUEUE_STATE has been negotiated. a driver MUST reset the s/negotiated./negotiated,/ > +device before getting the virtqueue state. Interesting approach, but it makes sense that the device must be stopped before we mess with the queue state :). I wonder whether requiring the device to keep state across reset will cause issues in the future or for testing/fuzzing. Another approach would have been to add a new status register bit for pausing the device. That reminds me of vhost. > + > +\devicenormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} > + > +If VIRTIO_F_QUEUE_STATE has been negotiated, a device MUST NOT clear > +the queue state upon reset and MUST reset the queue state when the > +driver sets ACKNOWLEDGE status bit. I only see normative sections mentioning getting the virtqueue state but not setting it. Please explain how setting works. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-23 10:27 ` [virtio-comment] " Stefan Hajnoczi @ 2021-03-24 8:15 ` Jason Wang 2021-03-24 9:35 ` Stefan Hajnoczi 2021-03-24 9:38 ` Stefan Hajnoczi 0 siblings, 2 replies; 19+ messages in thread From: Jason Wang @ 2021-03-24 8:15 UTC (permalink / raw) To: virtio-comment 在 2021/3/23 下午6:27, Stefan Hajnoczi 写道: > On Mon, Mar 22, 2021 at 11:47:16AM +0800, Jason Wang wrote: >> This patch adds new device facility to save and restore virtqueue >> state. The virtqueue state is split into two parts: >> >> - The available state: The state that is used for read the next >> available buffer. >> - The used state: The state that is used for make buffer used. >> >> This will simply the transport specific method implemention. E.g two >> le16 could be used instead of a single le32). For split virtqueue, we >> only need the available state since the used state is implemented in >> the virtqueue itself (the used index). For packed virtqueue, we need >> both the available state and the used state. >> >> Those states are required to implement live migration support for >> virtio device. >> >> Signed-off-by: Jason Wang <jasowang@redhat.com> >> --- >> content.tex | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 81 insertions(+) >> >> diff --git a/content.tex b/content.tex >> index 620c0e2..af39111 100644 >> --- a/content.tex >> +++ b/content.tex >> @@ -385,6 +385,83 @@ \section{Exporting Objects}\label{sec:Basic Facilities of a Virtio Device / Expo >> types. It is RECOMMENDED that devices generate version 4 >> UUIDs as specified by \hyperref[intro:rfc4122]{[RFC4122]}. >> >> +\section{Virtqueue State}\label{sec:Virtqueues / Virtqueue State} >> + >> +When VIRTIO_F_QUEUE_STATE is negotiated, the driver can set and >> +get the device internal virtqueue state through the following >> +fields. The way to access those fields is transport specific. >> + >> +\subsection{\field{Available State} Field} >> + >> +The availabe state field is two bytes virtqueue state that is used by > s/availabe/available/ > > s/bytes virtqueue state/bytes of virtqueue state/ Will fix all the above. > >> +the device to read for the next available buffer. >> + >> +When VIRTIO_RING_F_PACKED is not negotiated, it contains: >> + >> +\begin{lstlisting} >> +le16 last_avail_idx; >> +\end{lstlisting} >> + >> +The \field{last_avail_idx} field is the location where the device read >> +for the next index from the virtqueue available ring. > Perhaps this field can be defined in more detail: > > The \field{last_avail_idx} field is the free-running available ring > index where the device will read the next available head of a > descriptor chain. > > See also \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Available Ring}. Good point. > >> + >> +When VIRTIO_RING_F_PACKED is negotiated, it contains: >> + >> +\begin{lstlisting} >> +le16 { >> + last_avail_idx : 15; >> + last_avail_wrap_counter : 1; >> +}; >> +\end{lstlisting} >> + >> +The \field{last_avail_idx} field is the location where the device read >> +for the next descriptor from the virtqueue descriptor ring. > Similar wording as above can be used. Yes. > >> + >> +The \field{last_avail_wrap_counter} field is the last driver ring wrap >> +counter that is observed by the device. > s/is/was/? Ok. > >> + >> +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. >> + >> +\subsection{\field{Used State} Field} >> + >> +The availabe state field is two bytes virtqueue state that is used by > s/availabe/used/ Exactly. > > s/bytes virtqueue state/bytes of virtqueue state/ Right. > >> +the device to make buffer used. > s/to make buffer used/when marking a buffer used/ Ok. > >> + >> +When VIRTIO_RING_F_PACKED is negotiated, the used state contains: >> + >> +\begin{lstlisting} >> +le16 { >> + used_idx : 15; >> + used_wrap_counter : 1; >> +}; >> +\end{lstlisting} >> + >> +The \field{used_idx} field is the location where the device write next >> +used descriptor to the descriptor ring. > Similar as above. It should at least mention whether this is a > free-running index or always less than queue size. Yes, to be consistent, it should be free-running index. > >> + >> +The \field{used_wrap_counter} field is the wrap counter that is used >> +by the device. >> + >> +The used state is unnecessary when VIRTIO_RING_F_PACKED is not >> +negotiated. >> + >> +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. >> + >> +\drivernormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} >> + >> +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver MUST set the >> +state of each virtqueue after setting the FEATURE_OK status bit but >> +before setting the DRIVER_OK status bit. >> + >> +If VIRTIO_F_QUEUE_STATE has been negotiated. a driver MUST reset the > s/negotiated./negotiated,/ > >> +device before getting the virtqueue state. > Interesting approach, but it makes sense that the device must be stopped > before we mess with the queue state :). > > I wonder whether requiring the device to keep state across reset will > cause issues in the future or for testing/fuzzing. > > Another approach would have been to add a new status register bit for > pausing the device. That reminds me of vhost. That's the way I did here: https://lists.oasis-open.org/archives/virtio-comment/202012/msg00027.html > >> + >> +\devicenormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} >> + >> +If VIRTIO_F_QUEUE_STATE has been negotiated, a device MUST NOT clear >> +the queue state upon reset and MUST reset the queue state when the >> +driver sets ACKNOWLEDGE status bit. > I only see normative sections mentioning getting the virtqueue state but > not setting it. Please explain how setting works. You mean the device normative part? I think the description of avail state and used state can explain itself. Or I miss something? Thanks 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] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-24 8:15 ` Jason Wang @ 2021-03-24 9:35 ` Stefan Hajnoczi 2021-03-25 2:38 ` Jason Wang 2021-03-24 9:38 ` Stefan Hajnoczi 1 sibling, 1 reply; 19+ messages in thread From: Stefan Hajnoczi @ 2021-03-24 9:35 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment [-- Attachment #1: Type: text/plain, Size: 1008 bytes --] On Wed, Mar 24, 2021 at 04:15:55PM +0800, Jason Wang wrote: > 在 2021/3/23 下午6:27, Stefan Hajnoczi 写道: > > On Mon, Mar 22, 2021 at 11:47:16AM +0800, Jason Wang wrote: > > > + > > > +\devicenormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} > > > + > > > +If VIRTIO_F_QUEUE_STATE has been negotiated, a device MUST NOT clear > > > +the queue state upon reset and MUST reset the queue state when the > > > +driver sets ACKNOWLEDGE status bit. > > I only see normative sections mentioning getting the virtqueue state but > > not setting it. Please explain how setting works. > > > You mean the device normative part? I think the description of avail state > and used state can explain itself. Or I miss something? Oops, I missed the earlier normative section that says the driver must set the virtqueue state after FEATURES_OK but before DRIVER_OK. When re-reading I noticed that there is a typo: s/FEATURE_OK/FEATURES_OK/. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-24 9:35 ` Stefan Hajnoczi @ 2021-03-25 2:38 ` Jason Wang 0 siblings, 0 replies; 19+ messages in thread From: Jason Wang @ 2021-03-25 2:38 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: virtio-comment 在 2021/3/24 下午5:35, Stefan Hajnoczi 写道: > On Wed, Mar 24, 2021 at 04:15:55PM +0800, Jason Wang wrote: >> 在 2021/3/23 下午6:27, Stefan Hajnoczi 写道: >>> On Mon, Mar 22, 2021 at 11:47:16AM +0800, Jason Wang wrote: >>>> + >>>> +\devicenormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} >>>> + >>>> +If VIRTIO_F_QUEUE_STATE has been negotiated, a device MUST NOT clear >>>> +the queue state upon reset and MUST reset the queue state when the >>>> +driver sets ACKNOWLEDGE status bit. >>> I only see normative sections mentioning getting the virtqueue state but >>> not setting it. Please explain how setting works. >> >> You mean the device normative part? I think the description of avail state >> and used state can explain itself. Or I miss something? > Oops, I missed the earlier normative section that says the driver must > set the virtqueue state after FEATURES_OK but before DRIVER_OK. > > When re-reading I noticed that there is a typo: s/FEATURE_OK/FEATURES_OK/. Will fix. Thanks > > Stefan 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] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-24 8:15 ` Jason Wang 2021-03-24 9:35 ` Stefan Hajnoczi @ 2021-03-24 9:38 ` Stefan Hajnoczi 2021-03-25 2:42 ` Jason Wang 1 sibling, 1 reply; 19+ messages in thread From: Stefan Hajnoczi @ 2021-03-24 9:38 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment [-- Attachment #1: Type: text/plain, Size: 1724 bytes --] On Wed, Mar 24, 2021 at 04:15:55PM +0800, Jason Wang wrote: > 在 2021/3/23 下午6:27, Stefan Hajnoczi 写道: > > On Mon, Mar 22, 2021 at 11:47:16AM +0800, Jason Wang wrote: > > > +The \field{used_wrap_counter} field is the wrap counter that is used > > > +by the device. > > > + > > > +The used state is unnecessary when VIRTIO_RING_F_PACKED is not > > > +negotiated. > > > + > > > +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. > > > + > > > +\drivernormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} > > > + > > > +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver MUST set the > > > +state of each virtqueue after setting the FEATURE_OK status bit but > > > +before setting the DRIVER_OK status bit. > > > + > > > +If VIRTIO_F_QUEUE_STATE has been negotiated. a driver MUST reset the > > s/negotiated./negotiated,/ > > > > > +device before getting the virtqueue state. > > Interesting approach, but it makes sense that the device must be stopped > > before we mess with the queue state :). > > > > I wonder whether requiring the device to keep state across reset will > > cause issues in the future or for testing/fuzzing. > > > > Another approach would have been to add a new status register bit for > > pausing the device. That reminds me of vhost. > > > That's the way I did here: > https://lists.oasis-open.org/archives/virtio-comment/202012/msg00027.html That design seems less risky. I think modifying the semantics of device reset might end up being a problem. Defining an explicit paused state for saving/loading state seems cleaner. Why did you end up switching approaches? Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-24 9:38 ` Stefan Hajnoczi @ 2021-03-25 2:42 ` Jason Wang 2021-03-25 9:59 ` Stefan Hajnoczi 0 siblings, 1 reply; 19+ messages in thread From: Jason Wang @ 2021-03-25 2:42 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: virtio-comment [-- Attachment #1: Type: text/plain, Size: 2256 bytes --] 在 2021/3/24 下午5:38, Stefan Hajnoczi 写道: > On Wed, Mar 24, 2021 at 04:15:55PM +0800, Jason Wang wrote: >> 在 2021/3/23 下午6:27, Stefan Hajnoczi 写道: >>> On Mon, Mar 22, 2021 at 11:47:16AM +0800, Jason Wang wrote: >>>> +The \field{used_wrap_counter} field is the wrap counter that is used >>>> +by the device. >>>> + >>>> +The used state is unnecessary when VIRTIO_RING_F_PACKED is not >>>> +negotiated. >>>> + >>>> +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. >>>> + >>>> +\drivernormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} >>>> + >>>> +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver MUST set the >>>> +state of each virtqueue after setting the FEATURE_OK status bit but >>>> +before setting the DRIVER_OK status bit. >>>> + >>>> +If VIRTIO_F_QUEUE_STATE has been negotiated. a driver MUST reset the >>> s/negotiated./negotiated,/ >>> >>>> +device before getting the virtqueue state. >>> Interesting approach, but it makes sense that the device must be stopped >>> before we mess with the queue state :). >>> >>> I wonder whether requiring the device to keep state across reset will >>> cause issues in the future or for testing/fuzzing. >>> >>> Another approach would have been to add a new status register bit for >>> pausing the device. That reminds me of vhost. >> >> That's the way I did here: >> https://lists.oasis-open.org/archives/virtio-comment/202012/msg00027.html > That design seems less risky. I think modifying the semantics of device > reset might end up being a problem. Defining an explicit paused state > for saving/loading state seems cleaner. > > Why did you end up switching approaches? I try to seek some short-cut withut introducing new status bit but I end up realizing it might not work as expected. Another reason is that, by using new status bit, we need to ability to resume the device by clearing the bit which is somehow conflict with what spec requries: " 2.1.1 Driver Requirements: Device Status Field The driver MUST NOT clear adevice statusbit. " Maybe we can have an exception for the device stop/pause in this case. Thanks > > Stefan [-- Attachment #2: Type: text/html, Size: 5392 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility 2021-03-25 2:42 ` Jason Wang @ 2021-03-25 9:59 ` Stefan Hajnoczi 0 siblings, 0 replies; 19+ messages in thread From: Stefan Hajnoczi @ 2021-03-25 9:59 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment [-- Attachment #1: Type: text/plain, Size: 2812 bytes --] On Thu, Mar 25, 2021 at 10:42:38AM +0800, Jason Wang wrote: > > 在 2021/3/24 下午5:38, Stefan Hajnoczi 写道: > > On Wed, Mar 24, 2021 at 04:15:55PM +0800, Jason Wang wrote: > > > 在 2021/3/23 下午6:27, Stefan Hajnoczi 写道: > > > > On Mon, Mar 22, 2021 at 11:47:16AM +0800, Jason Wang wrote: > > > > > +The \field{used_wrap_counter} field is the wrap counter that is used > > > > > +by the device. > > > > > + > > > > > +The used state is unnecessary when VIRTIO_RING_F_PACKED is not > > > > > +negotiated. > > > > > + > > > > > +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}. > > > > > + > > > > > +\drivernormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State} > > > > > + > > > > > +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver MUST set the > > > > > +state of each virtqueue after setting the FEATURE_OK status bit but > > > > > +before setting the DRIVER_OK status bit. > > > > > + > > > > > +If VIRTIO_F_QUEUE_STATE has been negotiated. a driver MUST reset the > > > > s/negotiated./negotiated,/ > > > > > > > > > +device before getting the virtqueue state. > > > > Interesting approach, but it makes sense that the device must be stopped > > > > before we mess with the queue state :). > > > > > > > > I wonder whether requiring the device to keep state across reset will > > > > cause issues in the future or for testing/fuzzing. > > > > > > > > Another approach would have been to add a new status register bit for > > > > pausing the device. That reminds me of vhost. > > > > > > That's the way I did here: > > > https://lists.oasis-open.org/archives/virtio-comment/202012/msg00027.html > > That design seems less risky. I think modifying the semantics of device > > reset might end up being a problem. Defining an explicit paused state > > for saving/loading state seems cleaner. > > > > Why did you end up switching approaches? > > > I try to seek some short-cut withut introducing new status bit but I end up > realizing it might not work as expected. > > Another reason is that, by using new status bit, we need to ability to > resume the device by clearing the bit which is somehow conflict with what > spec requries: > > " > > 2.1.1 Driver Requirements: Device Status Field > > The driver MUST NOT clear adevice statusbit. > > " > > Maybe we can have an exception for the device stop/pause in this case. Yes, I think that is simply because the VIRTIO device lifecycle never needed to go back to a previous lifecycle state. It was a unidirectional state machine. The device stop/pause state seems like a valid case of going back to a previous lifecycle state and I don't think it breaks anything in the device model. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* [virtio-comment] [PATCH V2 2/2] virtio-pci: implement VIRTIO_F_QUEUE_STATE 2021-03-22 3:47 [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Jason Wang 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility Jason Wang @ 2021-03-22 3:47 ` Jason Wang 2021-03-23 10:02 ` Stefan Hajnoczi 2021-03-23 10:40 ` [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Stefan Hajnoczi 2 siblings, 1 reply; 19+ messages in thread From: Jason Wang @ 2021-03-22 3:47 UTC (permalink / raw) To: mst, virtio-comment Cc: eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford, Jason Wang This patch adds two new le16 fields to common configruation structure to support VIRTIO_F_QUEUE_STATE. Signed-off-by: Jason Wang <jasowang@redhat.com> --- content.tex | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/content.tex b/content.tex index af39111..adfc279 100644 --- a/content.tex +++ b/content.tex @@ -914,6 +914,8 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport le64 queue_driver; /* read-write */ le64 queue_device; /* read-write */ le16 queue_notify_data; /* read-only for driver */ + le16 queue_avail_state; /* read-write */ + le16 queue_used_state; /* read-write */ }; \end{lstlisting} @@ -993,6 +995,16 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport may benefit from providing another value, for example an internal virtqueue identifier, or an internal offset related to the virtqueue number. \end{note} + +\item[\field{queue_avail_state}] + This field exists only if VIRTIO_F_QUEUE_STATE has been + negotiated. The driver sets and gets the available state of + the virtqueue here (see \ref{sec:Virtqueues / Virtqueue State}). + +\item[\field{queue_used_state}] + This field exists only if VIRTIO_F_QUEUE_STATE has been + negotiated. The driver sets and gets the used state of the + virtqueue here (see \ref{sec:Virtqueues / Virtqueue State}). \end{description} \devicenormative{\paragraph}{Common configuration structure layout}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Common configuration structure layout} -- 2.24.3 (Apple Git-128) 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] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 2/2] virtio-pci: implement VIRTIO_F_QUEUE_STATE 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 2/2] virtio-pci: implement VIRTIO_F_QUEUE_STATE Jason Wang @ 2021-03-23 10:02 ` Stefan Hajnoczi 0 siblings, 0 replies; 19+ messages in thread From: Stefan Hajnoczi @ 2021-03-23 10:02 UTC (permalink / raw) To: Jason Wang Cc: mst, virtio-comment, eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford [-- Attachment #1: Type: text/plain, Size: 179 bytes --] On Mon, Mar 22, 2021 at 11:47:17AM +0800, Jason Wang wrote: > This patch adds two new le16 fields to common configruation structure If you respin: s/configruation/configuration/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE 2021-03-22 3:47 [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Jason Wang 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility Jason Wang 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 2/2] virtio-pci: implement VIRTIO_F_QUEUE_STATE Jason Wang @ 2021-03-23 10:40 ` Stefan Hajnoczi 2021-03-24 7:05 ` Jason Wang 2 siblings, 1 reply; 19+ messages in thread From: Stefan Hajnoczi @ 2021-03-23 10:40 UTC (permalink / raw) To: Jason Wang Cc: mst, virtio-comment, eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford [-- Attachment #1: Type: text/plain, Size: 1243 bytes --] On Mon, Mar 22, 2021 at 11:47:15AM +0800, Jason Wang wrote: > This is a new version to support VIRTIO_F_QUEUE_STATE. The feautre > extends the basic facility to allow the driver to set and get device > internal virtqueue state. This main motivation is to support live > migration of virtio devices. Can you describe the use cases that this interface covers as well as the steps involved in migrating a device? Traditionally live migration was transparent to the VIRTIO driver because it was performed by the hypervisor. I know you're aware but I think it's worth mentioning that this only supports stateless devices. Even the simple virtio-blk device has state in QEMU's implementation. If an I/O request fails it can be held by the device and resumed after live migration instead of failing the request immediately. The list of held requests needs to be migrated with the device and is not part of the virtqueue state. I'm concerned that using device reset will not work once this interface is extended to support device-specific state (e.g. the virtio-blk failed request list). There could be situations where reset really needs to reset (e.g. freeing I/O resources) and the device therefore cannot hold on to state across reset. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE 2021-03-23 10:40 ` [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Stefan Hajnoczi @ 2021-03-24 7:05 ` Jason Wang 2021-03-24 10:05 ` Stefan Hajnoczi 0 siblings, 1 reply; 19+ messages in thread From: Jason Wang @ 2021-03-24 7:05 UTC (permalink / raw) To: Stefan Hajnoczi Cc: mst, virtio-comment, eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford 在 2021/3/23 下午6:40, Stefan Hajnoczi 写道: > On Mon, Mar 22, 2021 at 11:47:15AM +0800, Jason Wang wrote: >> This is a new version to support VIRTIO_F_QUEUE_STATE. The feautre >> extends the basic facility to allow the driver to set and get device >> internal virtqueue state. This main motivation is to support live >> migration of virtio devices. > Can you describe the use cases that this interface covers as well as the > steps involved in migrating a device? Yes. I can describe the steps for live migrating virtio-net device. For other devices, we probably need other state. > Traditionally live migration was > transparent to the VIRTIO driver because it was performed by the > hypervisor. Right, but it could be possible that we may want live migrate between hardware virtio-pci devices. So it's up to the hypversior to save and restore states silently without the notice of guest driver as what we did for vhost. > > I know you're aware but I think it's worth mentioning that this only > supports stateless devices. Yes, that's why it's a queue state not a device state. > Even the simple virtio-blk device has state > in QEMU's implementation. If an I/O request fails it can be held by the > device and resumed after live migration instead of failing the request > immediately. The list of held requests needs to be migrated with the > device and is not part of the virtqueue state. Yes, I think we need to extend virtio spec to support save and restore device state. But anyway the virtqueue state is the infrastructure which should be introdouced first. > > I'm concerned that using device reset will not work once this interface > is extended to support device-specific state (e.g. the virtio-blk failed > request list). There could be situations where reset really needs to > reset (e.g. freeing I/O resources) and the device therefore cannot hold > on to state across reset. Good point. So here're some ways: 1) reuse device reset that is done in this patch 2) intorduce a new device status like what has been done in [1] 3) using queue_enable (as what has been done in the virtio-mmio, pci forbids to stop a queue currently, we may need to extend that) 4) use device specific way to stop the datapath Reusing device reset looks like a shortcut that might not be easy for stateful device as you said. 2) looks more general. 3) have the issues that it doesn't forbid the config changed. And 4) is also proposed by you and Michael. My understanding is that there should be no fundamental differences between 2) and 4). So I tend to respin [1], do you have any other ideas? Thanks [1] https://lists.oasis-open.org/archives/virtio-comment/202012/msg00027.html > > Stefan 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] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE 2021-03-24 7:05 ` Jason Wang @ 2021-03-24 10:05 ` Stefan Hajnoczi 2021-03-25 2:57 ` Jason Wang 0 siblings, 1 reply; 19+ messages in thread From: Stefan Hajnoczi @ 2021-03-24 10:05 UTC (permalink / raw) To: Jason Wang Cc: mst, virtio-comment, eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford [-- Attachment #1: Type: text/plain, Size: 3956 bytes --] On Wed, Mar 24, 2021 at 03:05:30PM +0800, Jason Wang wrote: > > 在 2021/3/23 下午6:40, Stefan Hajnoczi 写道: > > On Mon, Mar 22, 2021 at 11:47:15AM +0800, Jason Wang wrote: > > > This is a new version to support VIRTIO_F_QUEUE_STATE. The feautre > > > extends the basic facility to allow the driver to set and get device > > > internal virtqueue state. This main motivation is to support live > > > migration of virtio devices. > > Can you describe the use cases that this interface covers as well as the > > steps involved in migrating a device? > > > Yes. I can describe the steps for live migrating virtio-net device. For > other devices, we probably need other state. Thanks, describing the steps for virtio-net would be great. > > > > Traditionally live migration was > > transparent to the VIRTIO driver because it was performed by the > > hypervisor. > > > Right, but it could be possible that we may want live migrate between > hardware virtio-pci devices. So it's up to the hypversior to save and > restore states silently without the notice of guest driver as what we did > for vhost. This is where I'd like to understand the steps in detail. The set/get state functionality introduced in this spec change requires that the hypervisor has access to the device's hardware registers - the same registers that the guest is also using. I'd like to understand the lifecycle and how conflicts between the hypervisor and the guest are avoided (unless this is integrated into vDPA/VFIO/SR-IOV in a way that I haven't thought of?). > > > > > > I know you're aware but I think it's worth mentioning that this only > > supports stateless devices. > > > Yes, that's why it's a queue state not a device state. > > > > Even the simple virtio-blk device has state > > in QEMU's implementation. If an I/O request fails it can be held by the > > device and resumed after live migration instead of failing the request > > immediately. The list of held requests needs to be migrated with the > > device and is not part of the virtqueue state. > > > Yes, I think we need to extend virtio spec to support save and restore > device state. But anyway the virtqueue state is the infrastructure which > should be introdouced first. Introducing virtqueue state save/load first seems fine, but before committing to a spec cange we need an approximate plan for per-device state so that it's clear the design can be extended to cover that case in the future. > > > > I'm concerned that using device reset will not work once this interface > > is extended to support device-specific state (e.g. the virtio-blk failed > > request list). There could be situations where reset really needs to > > reset (e.g. freeing I/O resources) and the device therefore cannot hold > > on to state across reset. > > > Good point. So here're some ways: > > > 1) reuse device reset that is done in this patch > 2) intorduce a new device status like what has been done in [1] > 3) using queue_enable (as what has been done in the virtio-mmio, pci forbids > to stop a queue currently, we may need to extend that) > 4) use device specific way to stop the datapath > > Reusing device reset looks like a shortcut that might not be easy for > stateful device as you said. 2) looks more general. 3) have the issues that > it doesn't forbid the config changed. And 4) is also proposed by you and > Michael. > > My understanding is that there should be no fundamental differences between > 2) and 4). So I tend to respin [1], do you have any other ideas? 2 or 4 sound good. I prefer 2 since one standard interface will be less work and complexity than multiple device-specific ways of stopping the data path. 3 is more flexible but needs to be augmented with a way to pause the entire device. It could be added on top of 2 or 4, if necessary, in the future. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE 2021-03-24 10:05 ` Stefan Hajnoczi @ 2021-03-25 2:57 ` Jason Wang 2021-03-25 10:03 ` [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE\\ Stefan Hajnoczi 0 siblings, 1 reply; 19+ messages in thread From: Jason Wang @ 2021-03-25 2:57 UTC (permalink / raw) To: Stefan Hajnoczi Cc: mst, virtio-comment, eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford 在 2021/3/24 下午6:05, Stefan Hajnoczi 写道: > On Wed, Mar 24, 2021 at 03:05:30PM +0800, Jason Wang wrote: >> 在 2021/3/23 下午6:40, Stefan Hajnoczi 写道: >>> On Mon, Mar 22, 2021 at 11:47:15AM +0800, Jason Wang wrote: >>>> This is a new version to support VIRTIO_F_QUEUE_STATE. The feautre >>>> extends the basic facility to allow the driver to set and get device >>>> internal virtqueue state. This main motivation is to support live >>>> migration of virtio devices. >>> Can you describe the use cases that this interface covers as well as the >>> steps involved in migrating a device? >> >> Yes. I can describe the steps for live migrating virtio-net device. For >> other devices, we probably need other state. > Thanks, describing the steps for virtio-net would be great. > >> >>> Traditionally live migration was >>> transparent to the VIRTIO driver because it was performed by the >>> hypervisor. >> >> Right, but it could be possible that we may want live migrate between >> hardware virtio-pci devices. So it's up to the hypversior to save and >> restore states silently without the notice of guest driver as what we did >> for vhost. > This is where I'd like to understand the steps in detail. The set/get > state functionality introduced in this spec change requires that the > hypervisor has access to the device's hardware registers - the same > registers that the guest is also using. I'd like to understand the > lifecycle and how conflicts between the hypervisor and the guest are > avoided (unless this is integrated into vDPA/VFIO/SR-IOV in a way that I > haven't thought of?). Let's assume virito device is used through vhost-vdpa. In this case, there's actually two virtio devices 1) The device A that is used by vdpa driver and is connected to vdpa bus (vhost-vDPA). Usually it could be a virtio-pci device. 2) The device B that is emulated by Qemu. It could be virito-pci or even virtio-mmio device. So what guest driver can see is device B, and it can only access the status bit of device B. From the view of Qemu, device A works more like a vhost backend. It means it can stop device A (either via reset or other way like dedicated status bit) without noticing guest (touching the device status bit for device A). When we need to live migrate the VM: 1) Qemu need to stop device B (e.g stop vhost-vDPA) 2) Qemu get virtqueue states from device B 3) The virtqueue state will be passed from source to destinition 4) Qemu recovered the virtqueue states to device C which is the virtio/vDPA device that is on the destination 5) Qemu resume the dev C (e.g start vhost-vDPA) > >> >>> I know you're aware but I think it's worth mentioning that this only >>> supports stateless devices. >> >> Yes, that's why it's a queue state not a device state. >> >> >>> Even the simple virtio-blk device has state >>> in QEMU's implementation. If an I/O request fails it can be held by the >>> device and resumed after live migration instead of failing the request >>> immediately. The list of held requests needs to be migrated with the >>> device and is not part of the virtqueue state. >> >> Yes, I think we need to extend virtio spec to support save and restore >> device state. But anyway the virtqueue state is the infrastructure which >> should be introdouced first. > Introducing virtqueue state save/load first seems fine, but before > committing to a spec cange we need an approximate plan for per-device > state so that it's clear the design can be extended to cover that case > in the future. Yes, so as discussed. We might at least requires a API to fetch the inflight descriptors. Haven't thought it deeply but some possible ways: 1) transport specific way 2) generic method like a control vq command 1) looks simpler but may end up with function duplication, 2) may need some extension on the current virtio-blk. Actually we had 3), fetchn the information from the management deviec (like PF). > >>> I'm concerned that using device reset will not work once this interface >>> is extended to support device-specific state (e.g. the virtio-blk failed >>> request list). There could be situations where reset really needs to >>> reset (e.g. freeing I/O resources) and the device therefore cannot hold >>> on to state across reset. >> >> Good point. So here're some ways: >> >> >> 1) reuse device reset that is done in this patch >> 2) intorduce a new device status like what has been done in [1] >> 3) using queue_enable (as what has been done in the virtio-mmio, pci forbids >> to stop a queue currently, we may need to extend that) >> 4) use device specific way to stop the datapath >> >> Reusing device reset looks like a shortcut that might not be easy for >> stateful device as you said. 2) looks more general. 3) have the issues that >> it doesn't forbid the config changed. And 4) is also proposed by you and >> Michael. >> >> My understanding is that there should be no fundamental differences between >> 2) and 4). So I tend to respin [1], do you have any other ideas? > 2 or 4 sound good. I prefer 2 since one standard interface will be less > work and complexity than multiple device-specific ways of stopping the > data path. Yes. > > 3 is more flexible but needs to be augmented with a way to pause the > entire device. It could be added on top of 2 or 4, if necessary, in the > future. > > Stefan Right, let me try to continue the approach of new status bit to see if it works. Thanks 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] 19+ messages in thread
* Re: [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE\\ 2021-03-25 2:57 ` Jason Wang @ 2021-03-25 10:03 ` Stefan Hajnoczi 0 siblings, 0 replies; 19+ messages in thread From: Stefan Hajnoczi @ 2021-03-25 10:03 UTC (permalink / raw) To: Jason Wang Cc: mst, virtio-comment, eperezma, lulu, rob.miller, pasic, sgarzare, cohuck, jim.harford [-- Attachment #1: Type: text/plain, Size: 201 bytes --] On Thu, Mar 25, 2021 at 10:57:26AM +0800, Jason Wang wrote: > Right, let me try to continue the approach of new status bit to see if it > works. Thanks for the explanations, this sounds good. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-03-25 10:04 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-22 3:47 [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Jason Wang 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility Jason Wang 2021-03-22 8:19 ` [virtio-comment] " Eugenio Perez Martin 2021-03-23 2:54 ` Jason Wang 2021-03-23 9:27 ` Eugenio Perez Martin 2021-03-23 10:27 ` [virtio-comment] " Stefan Hajnoczi 2021-03-24 8:15 ` Jason Wang 2021-03-24 9:35 ` Stefan Hajnoczi 2021-03-25 2:38 ` Jason Wang 2021-03-24 9:38 ` Stefan Hajnoczi 2021-03-25 2:42 ` Jason Wang 2021-03-25 9:59 ` Stefan Hajnoczi 2021-03-22 3:47 ` [virtio-comment] [PATCH V2 2/2] virtio-pci: implement VIRTIO_F_QUEUE_STATE Jason Wang 2021-03-23 10:02 ` Stefan Hajnoczi 2021-03-23 10:40 ` [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Stefan Hajnoczi 2021-03-24 7:05 ` Jason Wang 2021-03-24 10:05 ` Stefan Hajnoczi 2021-03-25 2:57 ` Jason Wang 2021-03-25 10:03 ` [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE\\ Stefan Hajnoczi
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.