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:51:41 -0400	[thread overview]
Message-ID: <1460994701.3765.23.camel@infradead.org> (raw)
In-Reply-To: <20160418182320-mutt-send-email-mst@redhat.com>

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

On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote:
> 
> > 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?
> 
> No - it tells guest that e.g. the ACPI tables (or whatever the
> equivalent is) do not match reality with respect to this device
> since IOMMU is ignored by hypervisor.
> Hypervisor has no idea what does guest IOMMU code do - hopefully
> it is not actually broken.

OK, that makes sense — thanks.

So where the platform *does* have a way to coherently tell the guest
that some devices are behind and IOMMU and some aren't, we should never
see VIRTIO_F_IOMMU_PASSTHROUGH && !VIRTIO_F_IOMMU_PLATFORM. (Except
perhaps temporarily on x86 until we *do* fix the DMAR tables to tell
the truth; qv.)

This should *only* be a crutch for platforms which cannot properly
convey that information from the hypervisor to the guest. It should be
clearly documented "thou shalt not use this unless you've first
attempted to fix the broken platform to get it right for itself".

And if we look at it as such... does it make more sense for this to be
a more *generic* qemu←→guest interface? That way the software hacks can
live in the OS IOMMU code where they belong, and prevent assignment to
nested guests for example. And can cover cases like assigned PCI
devices in existing qemu/x86 which need the same treatment.

Put another way: if we're going to add code to the guest OS to look at
this information, why can't we add that code in the guest's IOMMU
support instead, to look at an out-of-band qemu-specific "ignore IOMMU
for these devices" list instead?

> The status quo is that that the IOMMU might well be bypassed
> and then you need to program physical addresses into the device,
> but maybe not. If DMA API does not give you physical addresses, you
> need to bypass it, but hypervisor does not know or care.

Right. The status quo is that qemu doesn't provide correct information
about IOMMU topology to guests, and they have to have heuristics to
work out whether to eschew the IOMMU for a given device or not. This is
true for virtio and assigned PCI devices alike.

Furthermore, some platforms don't *have* a standard way for qemu to
'tell the truth' to the guests, and that's where the real fun comes in.
But still, I'd like to see a generic solution for that lack instead of
a virtio-specific hack.

-- 
dwmw2



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

  reply	other threads:[~2016-04-18 15:51 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
2016-04-18 15:30           ` Michael S. Tsirkin
2016-04-18 15:51             ` David Woodhouse [this message]
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=1460994701.3765.23.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).