From: Laszlo Ersek <lersek@redhat.com>
To: Linux Virtualization <virtualization@lists.linux-foundation.org>,
Jon Masters <jcm@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Rusty Russell <rusty@rustcorp.com.au>
Cc: "Jordan Justen (Intel address)" <jordan.l.justen@intel.com>,
"edk2-devel@lists.sourceforge.net"
<edk2-devel@lists.sourceforge.net>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Olivier Martin <olivier.martin@arm.com>,
Mark Salter <msalter@redhat.com>
Subject: QueuePFN peculiarity in virtio-mmio
Date: Tue, 22 Oct 2013 19:49:21 +0200 [thread overview]
Message-ID: <5266BAA1.5080303@redhat.com> (raw)
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
WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: Linux Virtualization <virtualization@lists.linux-foundation.org>,
Jon Masters <jcm@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Rusty Russell <rusty@rustcorp.com.au>
Cc: "Jordan Justen (Intel address)" <jordan.l.justen@intel.com>,
"edk2-devel@lists.sourceforge.net"
<edk2-devel@lists.sourceforge.net>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Olivier Martin <olivier.martin@arm.com>,
Mark Salter <msalter@redhat.com>
Subject: [Qemu-devel] QueuePFN peculiarity in virtio-mmio
Date: Tue, 22 Oct 2013 19:49:21 +0200 [thread overview]
Message-ID: <5266BAA1.5080303@redhat.com> (raw)
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
next reply other threads:[~2013-10-22 17:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-22 17:49 Laszlo Ersek [this message]
2013-10-22 17:49 ` [Qemu-devel] QueuePFN peculiarity in virtio-mmio Laszlo Ersek
2013-10-22 17:55 ` Laszlo Ersek
2013-10-22 17:55 ` [Qemu-devel] " Laszlo Ersek
2013-10-22 18:05 ` [edk2] " Laszlo Ersek
2013-10-22 18:05 ` [Qemu-devel] " Laszlo Ersek
2013-10-23 1:07 ` Rusty Russell
2013-10-23 1:07 ` [Qemu-devel] " Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5266BAA1.5080303@redhat.com \
--to=lersek@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=edk2-devel@lists.sourceforge.net \
--cc=jcm@redhat.com \
--cc=jordan.l.justen@intel.com \
--cc=msalter@redhat.com \
--cc=olivier.martin@arm.com \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.