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

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 <[email protected]>
> > ---
> >  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