All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.