Re: [virtio-comment] device reset should entail QueuePFN reset (for all queues) on virtio-mmio

[Rusty Russell <rusty@au1.ibm.com>]

Laszlo Ersek <lersek@redhat.com> writes:
> Cross-posting from the Linux Virtualization list [1] with minor edits:
>
>
> "Appendix X: virtio-mmio" in the virtio spec says
>
>     * 0x040 | RW | QueuePFN
>       [...] When the Guest stops using the queue it must write zero
>       (0x0) to this register.
>       [...]
>
> and
>
>     Virtqueue Configuration
>
>     [...]
>     2. Check if the queue is not already in use: read QueuePFN
>     register, returned value should be zero (0x0).
>     [...]
>
> I think this is suboptimal per se, because a guest that crashes and
> reboots (while the emulator survives) will not be able to use the device
> after said reboot (it has never re-set QueuePFN to zero).
>
> But, more importantly: I think that resetting the device (by writing 0
> to its status register) should include (ie. *guarantee*) the effects of
> setting QueuePFN to zero for all imaginable queues of the device.
>
> This way, a defensive guest that starts up by resetting the device (*)
> after identifying it via MagicValue / Version / DeviceID / VendorID
> would be able to use the device regardless of the device's prior
> QueuePFN setting(s).
>
> (*) Resetting the device is the first step in "2.2.1 Device
> Initialization Sequence". It "is not required on initial start up", but
> as a guest driver can never be sure whether the startup in question is
> the initial one, a defensive driver will always start with device reet.
>
>
> The question arises because Olivier Martin posted a series to edk2-devel
> [2] that adds virtio-mmio support to TianoCore, and Mark Salter tested
> it [3] on an AArch64 foundation model with a Linux guest, and found
> problems. Namely, the UEFI firmware can drive the virtio devices via
> virtio-mmio, but the Linux kernel booted from it can not. The reason is
> the missing zeroing of QueuePFN across ExitBootServices(). (I'm just
> paraphrasing the analysis.)
>
> I think
> - that resetting the device (via its status register) should make the
>   host forget *all* prior configuration, including the QueuePFNs,
> - and that the Linux driver should reset the device as first step.
>
> So:
> - What's the motivation for the "acquire/release" semantics of QueuePFN?
> - Am I right that device reset should force a QueuePFN reset?

Hi Laszlo,

        The latching behaviour is basically a debugging helper, but
clearly device reset should set it to 0.

For the v2 layout proposed for the spec, we have this:

+* 0x03c | RW | QueueReady
+  Virtual queue ready bit.
+  Writing one (0x1) to this register notifies the Host that the
+  virtual queue is ready to be used. Reading from this register
+  returns the last value written to it. Both read and write
+  accesses apply to the queue selected by writing to QueueSel.
+  When the Guest wants to stop using the queue it must write
+  zero (0x0) to this register and read the value back to
+  ensure synchronisation.

I suggest we add:

   This register will be 0 on reset.

Cheers,
Rusty.