Re: QueuePFN peculiarity in virtio-mmio

2013-10-22 Thread 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
 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: QueuePFN peculiarity in virtio-mmio

2013-10-22 Thread Rusty Russell
Laszlo Ersek ler...@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-comm...@lists.oasis-open.org (yes, you will have
to subscribe to it, for IP reasons:
virtio-comment-subscr...@lists.oasis-open.org.

Thanks,
Rusty.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization