qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, peterx@redhat.com, cornelia.huck@de.ibm.com,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>, Amit Shah <amit.shah@redhat.com>,
	qemu-block@nongnu.org, Jason Wang <jasowang@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Wei Liu <wei.liu2@citrix.com>,
	virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api
Date: Mon, 18 Apr 2016 11:22:03 -0400	[thread overview]
Message-ID: <1460992923.3765.8.camel@infradead.org> (raw)
In-Reply-To: <20160418170534-mutt-send-email-mst@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

On Mon, 2016-04-18 at 17:23 +0300, Michael S. Tsirkin wrote:
> 
> This patch doesn't change DMAR tables, it creates a way for virtio
> device to tell guest "I obey what DMAR tables tell you, you can stop
> doing hacks".
> 
> And as PPC guys seem adamant that platform tools there are no good for
> that purpose, there's another bit that says "ignore what platform tells
> you, I'm not a real device - I'm part of hypervisor and I bypass the
> IOMMU".

...

+/* Request IOMMU passthrough (if available)
+ * Without VIRTIO_F_IOMMU_PLATFORM: bypass the IOMMU even if enabled.
+ * With VIRTIO_F_IOMMU_PLATFORM: suggest disabling IOMMU.
+ */
+#define VIRTIO_F_IOMMU_PASSTHROUGH     33
+
+/* Do not bypass the IOMMU (if configured) */
+#define VIRTIO_F_IOMMU_PLATFORM                34

OK... let's see if I can reconcile those descriptions coherently.

Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that
its own operating system's IOMMU code is expected to be broken, and
that the virtio driver should eschew the DMA API? And that the guest OS
cannot further assign the affected device to any of *its* nested
guests? Not that the broken IOMMU code in said guest OS will know the
latter, of course.

With VIRTIO_F_IOMMU_PLATFORM set, VIRTIO_F_IOMMU_PASSTHROUGH is just a
*hint*, suggesting that the guest OS should *request* a passthrough
mapping from the IOMMU? Via a driver←→IOMMU API which doesn't yet exist
in Linux, since we only have 'iommu=pt' on the command line for that?

And having *neither* of those bits sets is the status quo, which means
that your OS code might well be broken and need you to eschew the DMA
API, but maybe not.


-- 
dwmw2



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

  reply	other threads:[~2016-04-18 15:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18 11:47 [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api Michael S. Tsirkin
2016-04-18 11:58 ` David Woodhouse
2016-04-18 13:12   ` Michael S. Tsirkin
2016-04-18 14:03     ` David Woodhouse
2016-04-18 14:23       ` Michael S. Tsirkin
2016-04-18 15:22         ` David Woodhouse [this message]
2016-04-18 15:30           ` Michael S. Tsirkin
2016-04-18 15:51             ` David Woodhouse
2016-04-18 16:27               ` Michael S. Tsirkin
2016-04-18 18:29                 ` David Woodhouse
2016-04-18 19:24                   ` Andy Lutomirski
2016-04-19 10:27                     ` Michael S. Tsirkin
2016-04-19 16:02                       ` Andy Lutomirski
2016-04-19 16:09                         ` Michael S. Tsirkin
2016-04-19 16:12                           ` Andy Lutomirski
2016-04-19 16:20                             ` Michael S. Tsirkin
2016-04-19 16:26                               ` David Woodhouse
2016-04-19 17:49                                 ` Michael S. Tsirkin
2016-04-19 18:01                                   ` Andy Lutomirski
2016-04-19 20:16                                     ` Michael S. Tsirkin
2016-04-19 20:27                                       ` Andy Lutomirski
2016-04-19 20:54                                         ` Michael S. Tsirkin
2016-04-19 21:07                                           ` Andy Lutomirski
2016-04-20 13:14                                             ` Michael S. Tsirkin
2016-04-20 15:43                                               ` Andy Lutomirski
2016-04-19  9:13                   ` Michael S. Tsirkin
2016-04-19 14:44                     ` Alex Williamson
2016-04-19 16:00                     ` Andy Lutomirski
2016-04-19 16:04                       ` Michael S. Tsirkin

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=1460992923.3765.8.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=alex.williamson@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wei.liu2@citrix.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).