OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: device reset should entail QueuePFN reset (for all queues) on virtio-mmio

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.


    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.

- What's the motivation for the "acquire/release" semantics of QueuePFN?
- Am I right that device reset should force a QueuePFN reset?


[1] http://thread.gmane.org/gmane.linux.kernel.virtualization/21022
[2] http://thread.gmane.org/gmane.comp.bios.tianocore.devel/4557
[3] http://thread.gmane.org/gmane.comp.bios.tianocore.devel/4373/focus=4411

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]