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.