QueuePFN peculiarity in virtio-mmio

QueuePFN peculiarity in virtio-mmio

[Laszlo Ersek]

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

Re: QueuePFN peculiarity in virtio-mmio

[Laszlo Ersek]

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
> 

Re: [edk2] QueuePFN peculiarity in virtio-mmio

[Laszlo Ersek]

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

Re: QueuePFN peculiarity in virtio-mmio

[Rusty Russell]

Laszlo Ersek <lersek@redhat.com> writes:
> Hi,
>
> "Appendix X: virtio-mmio" in the virtio spec says

Hi 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@lists.oasis-open.org> (yes, you will have
to subscribe to it, for IP reasons:
virtio-comment-subscribe@lists.oasis-open.org.

Thanks,
Rusty.