[PATCH 0/1] transport-mmio: Add optional reset completion polling

[PATCH 0/1] transport-mmio: Add optional reset completion polling

[Peter Hilber]

Let devices using the MMIO transport avoid stalling the driver (virtual)
CPU during device reset, which requires introducing a new MMIO transport
version. This proposal is similar to [1], but simpler.

If the device reset includes terminating device activity which may
interfere with the driver, the reset should always have completed by the
time the driver considers the reset complete. After device reset, the
driver may free previously exposed buffers. Per the current MMIO transport
specification, the device must hence complete the reset during the write of
0 to the Status register. If terminating the device activity takes long,
the (virtual) CPU doing this write to the Status register must be stalled
for extended time, which may violate real-time requirements (including
those for hypervisor trap-and-emulate).

Address this by introducing a new MMIO transport version, v3, where the
driver must poll for reset completion, and, hence, the device reset does
not have to finish during the write of 0 to the Status register. Polling
for an operation to finish is a pattern also used for the PCI transport
device reset, device suspend, and MMIO transport QueueReset writes.

Unlike [1], this proposal does not require a reset-in-progress status bit.
Unlike [1], devices cannot indicate that the reset failed, which appears
unneeded.

This proposal has been verified with proof-of-concept implementations for
the Linux kernel and EDK2 OVMF Virtio drivers (supporting v2 and v3), and
for the QEMU Virtio devices.

[1] https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg07677.html

Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>


Peter Hilber (1):
  transport-mmio: Add v3, which polls for reset completion

 transport-mmio.tex | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)


base-commit: 5187698cc6f40fd2f2a714ca3faa6e998c5fc231
-- 
2.43.0

[PATCH 1/1] transport-mmio: Add v3, which polls for reset completion

[Peter Hilber]

Let devices using the MMIO transport avoid stalling the driver (virtual)
CPU during device reset, which requires introducing a new MMIO transport
version.

Unlike the PCI transport, the MMIO transport does not require the driver
to poll for reset completion. This requires a device using the MMIO
transport to complete reset during the write of 0 to the Status
register. Device reset may take more than 100 ms if it involves
terminating ongoing device activity which accesses driver memory. When
the (virtual) CPU writing 0 to the Status register needs to be stalled
during this, this may violate real-time requirements (including those
for hypervisor trap-and-emulate).

Address this by introducing a new MMIO transport version, v3, where the
driver must poll for reset completion, and, hence, the device reset does
not have to complete during the write to the Status register.

For clarity, also add some related requirements for v2. These
requirements are implied by the rest of the specification and therefore
do not alter the v2 semantics.

With MMIO transport v3, reset essentially works as with the PCI
transport, and the change is therefore not expected to cause problems.

Existing devices with MMIO transport v2 are not required to implement
v3, which will not work with current drivers. Drivers have to support
the MMIO transport versions of the used devices. Portable MMIO transport
drivers should therefore support both v2 and v3, which is simple.

Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
---
 transport-mmio.tex | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/transport-mmio.tex b/transport-mmio.tex
index 94a93a1..6504a6b 100644
--- a/transport-mmio.tex
+++ b/transport-mmio.tex
@@ -64,7 +64,8 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
   }
   \hline
   \mmioreg{Version}{Device version number}{0x004}{R}{%
-    0x2.
+    0x2 or 0x3. With version 0x3, the driver waits until it reads 0 from the
+    \field{Status} register before considering a reset complete.
     \begin{note}
       Legacy devices (see \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}~\nameref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}) used 0x1.
     \end{note}
@@ -262,13 +263,29 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
 
 The device MUST return 0x74726976 in \field{MagicValue}.
 
-The device MUST return value 0x2 in \field{Version}.
+The device MUST return value 0x2 or 0x3 in \field{Version}.
 
 The device MUST present each event by setting the corresponding bit in \field{InterruptStatus} from the
 moment it takes place, until the driver acknowledges the interrupt
 by writing a corresponding bit mask to the \field{InterruptACK} register.  Bits which
 do not represent events which took place MUST be zero.
 
+The device MUST reset when 0 is written to \field{Status}.
+
+While a reset is in progress, the device MUST retain the previous value of
+\field{Status}.
+
+For \field{Version} 0x2, the device MUST finish a reset before the driver's
+write of 0 to \field{Status} has completed.
+
+For \field{Version} 0x3, the device MAY continue with a reset after the driver's
+write of 0 to \field{Status} has completed.
+
+For \field{Version} 0x3, when \field{Status} is 0, the device MUST ignore
+further writes of 0 to \field{Status}.
+
+The device MUST present 0 in \field{Status} once it has finished the reset.
+
 Upon reset, the device MUST clear all bits in \field{InterruptStatus} and ready bits in the
 \field{QueueReady} register for all queues in the device.
 
@@ -305,7 +322,7 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
 The driver MUST ignore a device with \field{MagicValue} which is not 0x74726976,
 although it MAY report an error.
 
-The driver MUST ignore a device with \field{Version} which is not 0x2,
+The driver MUST ignore a device whose \field{Version} is neither 0x2 nor 0x3,
 although it MAY report an error.
 
 The driver MUST ignore a device with \field{DeviceID} 0x0,
@@ -331,6 +348,9 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
 The driver MUST write a value with a bit mask describing events it handled into \field{InterruptACK} when
 it finishes handling an interrupt and MUST NOT set any of the undefined bits in the value.
 
+For \field{Version} 0x3, the driver MUST NOT consider a reset complete before
+reading back 0 in \field{Status}.
+
 If VIRTIO_F_RING_RESET has been negotiated, after the driver writes 1 to
 \field{QueueReset} to reset the queue, the driver MUST NOT consider queue
 reset to be complete until it reads back 0 in \field{QueueReset}. The driver
-- 
2.43.0

Re: [PATCH 1/1] transport-mmio: Add v3, which polls for reset completion

[Matias Ezequiel Vara Larsen]

Hello Peter and sorry for the delay,

I used Claude to review it and I added some comments below:

On Wed, Feb 04, 2026 at 12:50:22PM +0100, Peter Hilber wrote:
> Let devices using the MMIO transport avoid stalling the driver (virtual)
> CPU during device reset, which requires introducing a new MMIO transport
> version.
> 
> Unlike the PCI transport, the MMIO transport does not require the driver
> to poll for reset completion. This requires a device using the MMIO
> transport to complete reset during the write of 0 to the Status
> register. Device reset may take more than 100 ms if it involves
> terminating ongoing device activity which accesses driver memory. When
> the (virtual) CPU writing 0 to the Status register needs to be stalled
> during this, this may violate real-time requirements (including those
> for hypervisor trap-and-emulate).
> 
> Address this by introducing a new MMIO transport version, v3, where the
> driver must poll for reset completion, and, hence, the device reset does
> not have to complete during the write to the Status register.
> 
> For clarity, also add some related requirements for v2. These
> requirements are implied by the rest of the specification and therefore
> do not alter the v2 semantics.
> 
> With MMIO transport v3, reset essentially works as with the PCI
> transport, and the change is therefore not expected to cause problems.
> 
> Existing devices with MMIO transport v2 are not required to implement
> v3, which will not work with current drivers. Drivers have to support
> the MMIO transport versions of the used devices. Portable MMIO transport
> drivers should therefore support both v2 and v3, which is simple.
> 
> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> ---
>  transport-mmio.tex | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/transport-mmio.tex b/transport-mmio.tex
> index 94a93a1..6504a6b 100644
> --- a/transport-mmio.tex
> +++ b/transport-mmio.tex
> @@ -64,7 +64,8 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
>    }
>    \hline
>    \mmioreg{Version}{Device version number}{0x004}{R}{%
> -    0x2.
> +    0x2 or 0x3. With version 0x3, the driver waits until it reads 0 from the
> +    \field{Status} register before considering a reset complete.

Shall we add something in the Status register too?,e.g., the driver may
or may not block when writing to this register. 

>      \begin{note}
>        Legacy devices (see \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}~\nameref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}) used 0x1.
>      \end{note}
> @@ -262,13 +263,29 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
>  
>  The device MUST return 0x74726976 in \field{MagicValue}.
>  
> -The device MUST return value 0x2 in \field{Version}.
> +The device MUST return value 0x2 or 0x3 in \field{Version}.
>  
>  The device MUST present each event by setting the corresponding bit in \field{InterruptStatus} from the
>  moment it takes place, until the driver acknowledges the interrupt
>  by writing a corresponding bit mask to the \field{InterruptACK} register.  Bits which
>  do not represent events which took place MUST be zero.
>  
> +The device MUST reset when 0 is written to \field{Status}.
> +
> +While a reset is in progress, the device MUST retain the previous value of
> +\field{Status}.

I think this may be inconsistent with the `Device Status` section:

`The \field{device status} field starts out as 0, and is reinitialized to 0 by
the device during reset.`

I think we could change in this sentence the word `during` by `after`.
This is a minor comment though because in v2 `during` and `after` is the
same from driver pov due to the sync semantics.

> +
> +For \field{Version} 0x2, the device MUST finish a reset before the driver's
> +write of 0 to \field{Status} has completed.
> +
> +For \field{Version} 0x3, the device MAY continue with a reset after the driver's
> +write of 0 to \field{Status} has completed.
> +
> +For \field{Version} 0x3, when \field{Status} is 0, the device MUST ignore
> +further writes of 0 to \field{Status}.
> +

Is this coherent with PCI? I guess the idea is to ignore if the reset is
in progress but in that case status is not zero yet.


> +The device MUST present 0 in \field{Status} once it has finished the reset.
> +
>  Upon reset, the device MUST clear all bits in \field{InterruptStatus} and ready bits in the
>  \field{QueueReady} register for all queues in the device.
>  
> @@ -305,7 +322,7 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
>  The driver MUST ignore a device with \field{MagicValue} which is not 0x74726976,
>  although it MAY report an error.
>  
> -The driver MUST ignore a device with \field{Version} which is not 0x2,
> +The driver MUST ignore a device whose \field{Version} is neither 0x2 nor 0x3,
>  although it MAY report an error.
>  
>  The driver MUST ignore a device with \field{DeviceID} 0x0,
> @@ -331,6 +348,9 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
>  The driver MUST write a value with a bit mask describing events it handled into \field{InterruptACK} when
>  it finishes handling an interrupt and MUST NOT set any of the undefined bits in the value.
>  
> +For \field{Version} 0x3, the driver MUST NOT consider a reset complete before
> +reading back 0 in \field{Status}.
> +
>  If VIRTIO_F_RING_RESET has been negotiated, after the driver writes 1 to
>  \field{QueueReset} to reset the queue, the driver MUST NOT consider queue
>  reset to be complete until it reads back 0 in \field{QueueReset}. The driver
> -- 
> 2.43.0
> 
> 

Re: [PATCH 1/1] transport-mmio: Add v3, which polls for reset completion

[Peter Hilber]

On Thu, Mar 26, 2026 at 07:44:01PM +0100, Matias Ezequiel Vara Larsen wrote:
> Hello Peter and sorry for the delay,
> 
> I used Claude to review it and I added some comments below:
> 
> On Wed, Feb 04, 2026 at 12:50:22PM +0100, Peter Hilber wrote:
> > Let devices using the MMIO transport avoid stalling the driver (virtual)
> > CPU during device reset, which requires introducing a new MMIO transport
> > version.
> > 
> > Unlike the PCI transport, the MMIO transport does not require the driver
> > to poll for reset completion. This requires a device using the MMIO
> > transport to complete reset during the write of 0 to the Status
> > register. Device reset may take more than 100 ms if it involves
> > terminating ongoing device activity which accesses driver memory. When
> > the (virtual) CPU writing 0 to the Status register needs to be stalled
> > during this, this may violate real-time requirements (including those
> > for hypervisor trap-and-emulate).
> > 
> > Address this by introducing a new MMIO transport version, v3, where the
> > driver must poll for reset completion, and, hence, the device reset does
> > not have to complete during the write to the Status register.
> > 
> > For clarity, also add some related requirements for v2. These
> > requirements are implied by the rest of the specification and therefore
> > do not alter the v2 semantics.
> > 
> > With MMIO transport v3, reset essentially works as with the PCI
> > transport, and the change is therefore not expected to cause problems.
> > 
> > Existing devices with MMIO transport v2 are not required to implement
> > v3, which will not work with current drivers. Drivers have to support
> > the MMIO transport versions of the used devices. Portable MMIO transport
> > drivers should therefore support both v2 and v3, which is simple.
> > 
> > Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> > ---
> >  transport-mmio.tex | 26 +++++++++++++++++++++++---
> >  1 file changed, 23 insertions(+), 3 deletions(-)
> > 
> > diff --git a/transport-mmio.tex b/transport-mmio.tex
> > index 94a93a1..6504a6b 100644
> > --- a/transport-mmio.tex
> > +++ b/transport-mmio.tex
> > @@ -64,7 +64,8 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
> >    }
> >    \hline
> >    \mmioreg{Version}{Device version number}{0x004}{R}{%
> > -    0x2.
> > +    0x2 or 0x3. With version 0x3, the driver waits until it reads 0 from the
> > +    \field{Status} register before considering a reset complete.
> 
> Shall we add something in the Status register too?,e.g., the driver may
> or may not block when writing to this register. 
> 

Agreed. How about adding this?

	Starting with \field{Version} 0x3, writing zero may not take
	effect immediately, and the driver waits until it reads back
	zero before considering a reset complete.


> >      \begin{note}
> >        Legacy devices (see \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}~\nameref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}) used 0x1.
> >      \end{note}
> > @@ -262,13 +263,29 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
> >  
> >  The device MUST return 0x74726976 in \field{MagicValue}.
> >  
> > -The device MUST return value 0x2 in \field{Version}.
> > +The device MUST return value 0x2 or 0x3 in \field{Version}.
> >  
> >  The device MUST present each event by setting the corresponding bit in \field{InterruptStatus} from the
> >  moment it takes place, until the driver acknowledges the interrupt
> >  by writing a corresponding bit mask to the \field{InterruptACK} register.  Bits which
> >  do not represent events which took place MUST be zero.
> >  
> > +The device MUST reset when 0 is written to \field{Status}.
> > +
> > +While a reset is in progress, the device MUST retain the previous value of
> > +\field{Status}.
> 
> I think this may be inconsistent with the `Device Status` section:
> 
> `The \field{device status} field starts out as 0, and is reinitialized to 0 by
> the device during reset.`
> 
> I think we could change in this sentence the word `during` by `after`.
> This is a minor comment though because in v2 `during` and `after` is the
> same from driver pov due to the sync semantics.
> 

The `Device Status` section applies to all transports.  Would this not
change allowed behavior?  Maybe it would be better to add the MMIO
requirement only for MMIO v3 and in this different form?

	For \field{Version} 0x3, the device MUST change \field{Status}
	to 0 as the last step of the reset.

> > +
> > +For \field{Version} 0x2, the device MUST finish a reset before the driver's
> > +write of 0 to \field{Status} has completed.
> > +
> > +For \field{Version} 0x3, the device MAY continue with a reset after the driver's
> > +write of 0 to \field{Status} has completed.
> > +
> > +For \field{Version} 0x3, when \field{Status} is 0, the device MUST ignore
> > +further writes of 0 to \field{Status}.
> > +
> 
> Is this coherent with PCI? I guess the idea is to ignore if the reset is
> in progress but in that case status is not zero yet.
> 
> 

The intent for this requirement is to avoid ambiguity about when a reset
would complete when status is already zero. The following should not
happen:

  DRIVER                          DEVICE

  wr(Status, 0)
                                  reset starts
                                  reset completes
                                  Status = 0

  rd(Status) -> 0

  wr(Status, 0)                   [second reset triggered]
                                  reset starts

  rd(Status) -> 0                 [!] reset still in progress

  read MagicValue, Version, DeviceID

  wr(Status, ACKNOWLEDGE)
                                  reset completes late
                                  Status = 0  [!] clobbers ACKNOWLEDGE

Thank you for the review!

Peter

> > +The device MUST present 0 in \field{Status} once it has finished the reset.
> > +
> >  Upon reset, the device MUST clear all bits in \field{InterruptStatus} and ready bits in the
> >  \field{QueueReady} register for all queues in the device.
> >  
> > @@ -305,7 +322,7 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
> >  The driver MUST ignore a device with \field{MagicValue} which is not 0x74726976,
> >  although it MAY report an error.
> >  
> > -The driver MUST ignore a device with \field{Version} which is not 0x2,
> > +The driver MUST ignore a device whose \field{Version} is neither 0x2 nor 0x3,
> >  although it MAY report an error.
> >  
> >  The driver MUST ignore a device with \field{DeviceID} 0x0,
> > @@ -331,6 +348,9 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
> >  The driver MUST write a value with a bit mask describing events it handled into \field{InterruptACK} when
> >  it finishes handling an interrupt and MUST NOT set any of the undefined bits in the value.
> >  
> > +For \field{Version} 0x3, the driver MUST NOT consider a reset complete before
> > +reading back 0 in \field{Status}.
> > +
> >  If VIRTIO_F_RING_RESET has been negotiated, after the driver writes 1 to
> >  \field{QueueReset} to reset the queue, the driver MUST NOT consider queue
> >  reset to be complete until it reads back 0 in \field{QueueReset}. The driver
> > -- 
> > 2.43.0
> > 
> > 
> 

Re: [PATCH 1/1] transport-mmio: Add v3, which polls for reset completion

[Michael S. Tsirkin]

On Wed, Feb 04, 2026 at 12:50:22PM +0100, Peter Hilber wrote:
> Let devices using the MMIO transport avoid stalling the driver (virtual)
> CPU during device reset, which requires introducing a new MMIO transport
> version.
> 
> Unlike the PCI transport, the MMIO transport does not require the driver
> to poll for reset completion. This requires a device using the MMIO
> transport to complete reset during the write of 0 to the Status
> register. Device reset may take more than 100 ms if it involves
> terminating ongoing device activity which accesses driver memory. When
> the (virtual) CPU writing 0 to the Status register needs to be stalled
> during this, this may violate real-time requirements (including those
> for hypervisor trap-and-emulate).
> 
> Address this by introducing a new MMIO transport version, v3, where the
> driver must poll for reset completion, and, hence, the device reset does
> not have to complete during the write to the Status register.
> 
> For clarity, also add some related requirements for v2. These
> requirements are implied by the rest of the specification and therefore
> do not alter the v2 semantics.
> 
> With MMIO transport v3, reset essentially works as with the PCI
> transport, and the change is therefore not expected to cause problems.
> 
> Existing devices with MMIO transport v2 are not required to implement
> v3, which will not work with current drivers. Drivers have to support
> the MMIO transport versions of the used devices. Portable MMIO transport
> drivers should therefore support both v2 and v3, which is simple.
> 
> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> ---
>  transport-mmio.tex | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/transport-mmio.tex b/transport-mmio.tex
> index 94a93a1..6504a6b 100644
> --- a/transport-mmio.tex
> +++ b/transport-mmio.tex
> @@ -64,7 +64,8 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
>    }
>    \hline
>    \mmioreg{Version}{Device version number}{0x004}{R}{%
> -    0x2.
> +    0x2 or 0x3. With version 0x3, the driver waits until it reads 0 from the
> +    \field{Status} register before considering a reset complete.
>      \begin{note}
>        Legacy devices (see \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}~\nameref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}) used 0x1.
>      \end{note}

But this means there's no way to support existing (non polling) and new (polling)
drivers both in the same hypervisor:

        /* Check device version */
        vm_dev->version = readl(vm_dev->base + VIRTIO_MMIO_VERSION);
        if (vm_dev->version < 1 || vm_dev->version > 2) {
                dev_err(&pdev->dev, "Version %ld not supported!\n",
                                vm_dev->version);
                rc = -ENXIO;
                goto free_vm_dev;
        }



Don't we want to?



-- 
MST

Re: [PATCH 1/1] transport-mmio: Add v3, which polls for reset completion

[Peter Hilber]

On Thu, Mar 26, 2026 at 07:13:59PM -0400, Michael S. Tsirkin wrote:
> On Wed, Feb 04, 2026 at 12:50:22PM +0100, Peter Hilber wrote:
> > Let devices using the MMIO transport avoid stalling the driver (virtual)
> > CPU during device reset, which requires introducing a new MMIO transport
> > version.
> > 
> > Unlike the PCI transport, the MMIO transport does not require the driver
> > to poll for reset completion. This requires a device using the MMIO
> > transport to complete reset during the write of 0 to the Status
> > register. Device reset may take more than 100 ms if it involves
> > terminating ongoing device activity which accesses driver memory. When
> > the (virtual) CPU writing 0 to the Status register needs to be stalled
> > during this, this may violate real-time requirements (including those
> > for hypervisor trap-and-emulate).
> > 
> > Address this by introducing a new MMIO transport version, v3, where the
> > driver must poll for reset completion, and, hence, the device reset does
> > not have to complete during the write to the Status register.
> > 
> > For clarity, also add some related requirements for v2. These
> > requirements are implied by the rest of the specification and therefore
> > do not alter the v2 semantics.
> > 
> > With MMIO transport v3, reset essentially works as with the PCI
> > transport, and the change is therefore not expected to cause problems.
> > 
> > Existing devices with MMIO transport v2 are not required to implement
> > v3, which will not work with current drivers. Drivers have to support
> > the MMIO transport versions of the used devices. Portable MMIO transport
> > drivers should therefore support both v2 and v3, which is simple.
> > 
> > Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> > ---
> >  transport-mmio.tex | 26 +++++++++++++++++++++++---
> >  1 file changed, 23 insertions(+), 3 deletions(-)
> > 
> > diff --git a/transport-mmio.tex b/transport-mmio.tex
> > index 94a93a1..6504a6b 100644
> > --- a/transport-mmio.tex
> > +++ b/transport-mmio.tex
> > @@ -64,7 +64,8 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
> >    }
> >    \hline
> >    \mmioreg{Version}{Device version number}{0x004}{R}{%
> > -    0x2.
> > +    0x2 or 0x3. With version 0x3, the driver waits until it reads 0 from the
> > +    \field{Status} register before considering a reset complete.
> >      \begin{note}
> >        Legacy devices (see \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}~\nameref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}) used 0x1.
> >      \end{note}
> 
> But this means there's no way to support existing (non polling) and new (polling)
> drivers both in the same hypervisor:
> 
>         /* Check device version */
>         vm_dev->version = readl(vm_dev->base + VIRTIO_MMIO_VERSION);
>         if (vm_dev->version < 1 || vm_dev->version > 2) {
>                 dev_err(&pdev->dev, "Version %ld not supported!\n",
>                                 vm_dev->version);
>                 rc = -ENXIO;
>                 goto free_vm_dev;
>         }
> 
> 
> 
> Don't we want to?

In my understanding, a driver can easily be modified to support both
version 2 and 3.

My assumption is that if a hypervisor requires reset with polling (v3),
then it cannot correctly implement the MMIO v2 reset semantics within
its operating constraints, and therefore must not advertise v2.  For all
device implementations which can work with MMIO transport v2, there
would be no incentive to upgrade to v3 for now.

If a hypervisor prefers reset with polling, but does not mandate it, in
my understanding it would have to use an out-of-spec mechanism.  Maybe
the hypervisor could offer both v2 and v3 devices and add a device tree
property to the v2 devices telling that a preferred v3 device should be
used instead.  But I am not aware about such a use case.

Thanks for the comment,

Peter

Re: [PATCH 0/1] transport-mmio: Add optional reset completion polling

[Peter Hilber]

On Wed, Feb 04, 2026 at 12:50:21PM +0100, Peter Hilber wrote:
> Let devices using the MMIO transport avoid stalling the driver (virtual)
> CPU during device reset, which requires introducing a new MMIO transport
> version. This proposal is similar to [1], but simpler.
> 
> If the device reset includes terminating device activity which may
> interfere with the driver, the reset should always have completed by the
> time the driver considers the reset complete. After device reset, the
> driver may free previously exposed buffers. Per the current MMIO transport
> specification, the device must hence complete the reset during the write of
> 0 to the Status register. If terminating the device activity takes long,
> the (virtual) CPU doing this write to the Status register must be stalled
> for extended time, which may violate real-time requirements (including
> those for hypervisor trap-and-emulate).
> 
> Address this by introducing a new MMIO transport version, v3, where the
> driver must poll for reset completion, and, hence, the device reset does
> not have to finish during the write of 0 to the Status register. Polling
> for an operation to finish is a pattern also used for the PCI transport
> device reset, device suspend, and MMIO transport QueueReset writes.

This patch has been pending for one month without replies. Any review or
feedback would be very welcome.

Best regards,

Peter

> 
> Unlike [1], this proposal does not require a reset-in-progress status bit.
> Unlike [1], devices cannot indicate that the reset failed, which appears
> unneeded.
> 
> This proposal has been verified with proof-of-concept implementations for
> the Linux kernel and EDK2 OVMF Virtio drivers (supporting v2 and v3), and
> for the QEMU Virtio devices.
> 
> [1] https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg07677.html
> 
> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> 
> 
> Peter Hilber (1):
>   transport-mmio: Add v3, which polls for reset completion
> 
>  transport-mmio.tex | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> 
> base-commit: 5187698cc6f40fd2f2a714ca3faa6e998c5fc231
> -- 
> 2.43.0
>