Hi,
"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 in itself is already suboptimal, because a guest that
crashes and reboots (while the emulator itself 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 has posted a series to edk2-devel
that adds virtio-mmio support to TianoCore, and Mark tested it (using
OVMF) with a Linux guest and found problems. Namely, OVMF itself can
drive the virtio devices via virtio-mmio, but the Linux kernel booted
from OVMF can not. The reason is the missing zeroing of QueuePFN when
OVMF is exiting. (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 QueuePFN,
- 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 release too?
Thanks,
Laszlo
My apologies, I used Anthony's previous (now obsolete) email. Updated it now & keeping full context below. Sorry. On 10/22/13 19:49, Laszlo Ersek wrote:> Hi, > > "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 in itself is already suboptimal, because a guest that > crashes and reboots (while the emulator itself 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 has posted a series to edk2-devel > that adds virtio-mmio support to TianoCore, and Mark tested it (using > OVMF) with a Linux guest and found problems. Namely, OVMF itself can > drive the virtio devices via virtio-mmio, but the Linux kernel booted > from OVMF can not. The reason is the missing zeroing of QueuePFN when > OVMF is exiting. (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 QueuePFN, > - 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 release too? > > Thanks, > Laszlo >
On 10/22/13 19:55, Laszlo Ersek wrote:>> The question arises because Olivier has posted a series to edk2-devel >> that adds virtio-mmio support to TianoCore, and Mark tested it (using >> OVMF) with a Linux guest and found problems. Namely, OVMF itself can >> drive the virtio devices via virtio-mmio, but the Linux kernel booted >> from OVMF can not. The reason is the missing zeroing of QueuePFN when >> OVMF is exiting. (I'm just paraphrasing the analysis.)s/OVMF/AArch64 foundation model/g http://thread.gmane.org/gmane.comp.bios.tianocore.devel/4373/focus=4411 I should have followed my own advice, not to post when sick. I'll go now and hide in a cave. Laszlo /facepalm
Laszlo Ersek <lersek at redhat.com> writes:> Hi, > > "Appendix X: virtio-mmio" in the virtio spec saysHi Laszlo, You're in luck! We're currently revising the virtio spec under the OASIS banner. I'd really like you to post your suggestion to their mailing list <virtio-comment at lists.oasis-open.org> (yes, you will have to subscribe to it, for IP reasons: virtio-comment-subscribe at lists.oasis-open.org. Thanks, Rusty.