All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	Andy Lutomirski <luto@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Joerg Roedel <jroedel@suse.de>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Christoph Hellwig <hch@lst.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	KVM <kvm@vger.kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff
Date: Fri, 30 Oct 2015 16:54:58 +0000	[thread overview]
Message-ID: <1446224098.25261.15.camel@infradead.org> (raw)
In-Reply-To: <20151029104301-mutt-send-email-mst@redhat.com>

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

(Sorry, missed part of this before).

On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote:
> Isn't this specified by the hypervisor? I don't think this is a good
> way to do this: guest security should be up to guest.

And it is. When the guest sees an IOMMU, it can choose to use it, or
choose not to (or choose to put it in passthrough mode). But as Jörg
says, we don't have a way for an individual  device driver to *request*
passthrough mode or not yet; the choice is made by the core IOMMU code
(iommu=pt on the command line) — or by the platform simply stating that
a given device isn't *covered* by an IOMMU, if that is indeed the case.

In *no* circumstance is it sane for a device driver just to "opt out"
of using the correct DMA API function calls, and expect that to
*magically* cause the IOMMU to be bypassed.

> > Everyone seems to agree that x86's emulated Q35 thing
> > is just buggy right now and should be taught to use the existing ACPI
> > mechanism for enumerating passthrough devices.
> 
> I'm not sure what ACPI has to do with it.
> It's about a way for guest users to specify whether
> they want to bypass an IOMMU for a given device.

No, it absolutely isn't. You might want that — and see the discussion
about DMA_ATTR_IOMMU_BYPASS if you do. But that is *utterly* irrelevant
to *this* discussion, in which you seem to be advocating that the
virtio drivers should remain buggy by just unilaterally not using the
DMA API.

> By the way, a bunch of code is missing on the QEMU side
> to make this useful:
> 1. virtio ignores the iommu
> 2. vhost user ignores the iommu
> 3. dataplane ignores the iommu
> 4. vhost-net ignores the iommu
> 5. VFIO ignores the iommu

No, those things are not useful for fixing the virtio driver bug under
discussion here. All we need to do is make the virtio drivers correctly
use the DMA API. They should never have passed review and been accepted
into the Linux kernel without that.

All we need to do first is make sure that the bug we have in the
PowerPC IOMMU code (and potentially ARM and/or SPARC?) is fixed, and
that it doesn't attempt to use an IOMMU that doesn't exist. And ensure
that the virtualised IOMMU on qemu/x86 isn't lying and claiming that it
translates for the virtio devices when it doesn't.

There are other things we might want to do — like fixing the IOMMU that
qemu can emulate, and actually making it work with real assigned
devices (currently it's totally hosed because it doesn't handle that
case at all). And potentially making the virtualised IOMMU actually
*do* translation for virtio devices (as opposed to just admitting
correctly that it doesn't). But those aren't strictly relevant here,
yet.

It's not clear what specific uses of the IOMMU you had in mind in your
above list — could you elucidate?

-- 
dwmw2


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

WARNING: multiple messages have this Message-ID (diff)
From: David Woodhouse <dwmw2@infradead.org>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
	Joerg Roedel <jroedel@suse.de>, KVM <kvm@vger.kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Christoph Hellwig <hch@lst.de>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff
Date: Fri, 30 Oct 2015 16:54:58 +0000	[thread overview]
Message-ID: <1446224098.25261.15.camel@infradead.org> (raw)
In-Reply-To: <20151029104301-mutt-send-email-mst@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 2882 bytes --]

(Sorry, missed part of this before).

On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote:
> Isn't this specified by the hypervisor? I don't think this is a good
> way to do this: guest security should be up to guest.

And it is. When the guest sees an IOMMU, it can choose to use it, or
choose not to (or choose to put it in passthrough mode). But as Jörg
says, we don't have a way for an individual  device driver to *request*
passthrough mode or not yet; the choice is made by the core IOMMU code
(iommu=pt on the command line) — or by the platform simply stating that
a given device isn't *covered* by an IOMMU, if that is indeed the case.

In *no* circumstance is it sane for a device driver just to "opt out"
of using the correct DMA API function calls, and expect that to
*magically* cause the IOMMU to be bypassed.

> > Everyone seems to agree that x86's emulated Q35 thing
> > is just buggy right now and should be taught to use the existing ACPI
> > mechanism for enumerating passthrough devices.
> 
> I'm not sure what ACPI has to do with it.
> It's about a way for guest users to specify whether
> they want to bypass an IOMMU for a given device.

No, it absolutely isn't. You might want that — and see the discussion
about DMA_ATTR_IOMMU_BYPASS if you do. But that is *utterly* irrelevant
to *this* discussion, in which you seem to be advocating that the
virtio drivers should remain buggy by just unilaterally not using the
DMA API.

> By the way, a bunch of code is missing on the QEMU side
> to make this useful:
> 1. virtio ignores the iommu
> 2. vhost user ignores the iommu
> 3. dataplane ignores the iommu
> 4. vhost-net ignores the iommu
> 5. VFIO ignores the iommu

No, those things are not useful for fixing the virtio driver bug under
discussion here. All we need to do is make the virtio drivers correctly
use the DMA API. They should never have passed review and been accepted
into the Linux kernel without that.

All we need to do first is make sure that the bug we have in the
PowerPC IOMMU code (and potentially ARM and/or SPARC?) is fixed, and
that it doesn't attempt to use an IOMMU that doesn't exist. And ensure
that the virtualised IOMMU on qemu/x86 isn't lying and claiming that it
translates for the virtio devices when it doesn't.

There are other things we might want to do — like fixing the IOMMU that
qemu can emulate, and actually making it work with real assigned
devices (currently it's totally hosed because it doesn't handle that
case at all). And potentially making the virtualised IOMMU actually
*do* translation for virtio devices (as opposed to just admitting
correctly that it doesn't). But those aren't strictly relevant here,
yet.

It's not clear what specific uses of the IOMMU you had in mind in your
above list — could you elucidate?

-- 
dwmw2


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

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

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

  parent reply	other threads:[~2015-10-30 16:55 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28  6:38 [PATCH v3 0/3] virtio DMA API core stuff Andy Lutomirski
2015-10-28  6:38 ` [PATCH v3 1/3] virtio_net: Stop doing DMA from the stack Andy Lutomirski
2015-10-28  7:08   ` Michael S. Tsirkin
2015-10-28  7:08   ` Michael S. Tsirkin
2015-10-28  6:38 ` Andy Lutomirski
2015-10-28  6:38 ` [PATCH v3 2/3] virtio_ring: Support DMA APIs Andy Lutomirski
2015-10-28  6:38 ` Andy Lutomirski
2015-10-28  6:39 ` [PATCH v3 3/3] virtio_pci: Use the DMA API Andy Lutomirski
2015-10-28  6:39 ` Andy Lutomirski
2015-10-28  6:53 ` [PATCH v3 0/3] virtio DMA API core stuff David Woodhouse
2015-10-28  6:53   ` David Woodhouse
2015-10-28  7:09   ` Andy Lutomirski
2015-10-28  7:09   ` Andy Lutomirski
2015-10-28  7:17 ` Michael S. Tsirkin
2015-10-28  7:17   ` Michael S. Tsirkin
2015-10-28  7:40   ` Christian Borntraeger
2015-10-28  7:40     ` Christian Borntraeger
2015-10-28  8:09     ` David Woodhouse
2015-10-28  8:09       ` David Woodhouse
2015-10-28 11:35       ` Michael S. Tsirkin
2015-10-28 11:35         ` Michael S. Tsirkin
2015-10-28 13:35         ` David Woodhouse
2015-10-28 13:35           ` David Woodhouse
2015-10-28 14:05           ` Michael S. Tsirkin
2015-10-28 14:05             ` Michael S. Tsirkin
2015-10-28 14:13             ` David Woodhouse
2015-10-28 14:13               ` David Woodhouse
2015-10-28 14:22               ` Michael S. Tsirkin
2015-10-28 14:22                 ` Michael S. Tsirkin
2015-10-28 14:32                 ` David Woodhouse
2015-10-28 14:32                   ` David Woodhouse
2015-10-28 16:12                   ` Michael S. Tsirkin
2015-10-28 22:51                     ` Andy Lutomirski
2015-10-28 22:51                       ` Andy Lutomirski
2015-10-29  9:01                       ` Michael S. Tsirkin
2015-10-29  9:01                         ` Michael S. Tsirkin
2015-10-29 16:18                         ` David Woodhouse
2015-10-29 16:18                           ` David Woodhouse
2015-11-08 10:37                           ` Michael S. Tsirkin
2015-11-08 10:37                             ` Michael S. Tsirkin
2015-11-08 11:49                             ` Joerg Roedel
2015-11-08 11:49                               ` Joerg Roedel
2015-11-10 15:02                               ` Michael S. Tsirkin
2015-11-10 15:02                                 ` Michael S. Tsirkin
2015-11-10 18:54                                 ` Andy Lutomirski
2015-11-10 18:54                                   ` Andy Lutomirski
2015-11-11 10:05                                   ` Michael S. Tsirkin
2015-11-11 10:05                                     ` Michael S. Tsirkin
2015-11-11 15:56                                     ` Andy Lutomirski
2015-11-11 22:30                                       ` David Woodhouse
2015-11-11 22:30                                       ` David Woodhouse
2015-11-12 11:09                                         ` Michael S. Tsirkin
2015-11-12 11:09                                           ` Michael S. Tsirkin
2015-11-12 12:18                                           ` David Woodhouse
2015-11-12 12:18                                             ` David Woodhouse
2015-11-11 15:56                                     ` Andy Lutomirski
2015-11-22 13:06                               ` Marcel Apfelbaum
2015-11-22 13:06                                 ` Marcel Apfelbaum
2015-11-22 15:54                                 ` David Woodhouse
2015-11-22 15:54                                   ` David Woodhouse
2015-11-22 17:04                                   ` Marcel Apfelbaum
2015-11-22 17:04                                   ` Marcel Apfelbaum
2015-11-22 22:11                                   ` Michael S. Tsirkin
2015-11-22 22:11                                     ` Michael S. Tsirkin
2015-11-08 12:00                             ` David Woodhouse
2015-11-08 12:00                               ` David Woodhouse
2015-10-30 15:16                         ` Joerg Roedel
2015-10-30 15:16                         ` Joerg Roedel
2015-11-11  9:11                           ` Michael S. Tsirkin
2015-11-11  9:11                             ` Michael S. Tsirkin
2015-10-30 16:54                         ` David Woodhouse [this message]
2015-10-30 16:54                           ` David Woodhouse
2015-11-03 10:24                         ` Paolo Bonzini
2015-11-03 10:24                         ` Paolo Bonzini
2015-10-28 16:12                   ` Michael S. Tsirkin
2015-10-28  8:36     ` Benjamin Herrenschmidt
2015-10-28  8:36       ` Benjamin Herrenschmidt
2015-10-28 11:23       ` Michael S. Tsirkin
2015-10-28 11:23         ` Michael S. Tsirkin
2015-10-28 13:37         ` David Woodhouse
2015-10-28 13:37           ` David Woodhouse
2015-10-28 14:07           ` Michael S. Tsirkin
2015-10-28 14:07             ` Michael S. Tsirkin
2015-11-19 13:45 ` Michael S. Tsirkin
2015-11-19 13:45 ` Michael S. Tsirkin
2015-11-19 21:59   ` Andy Lutomirski
2015-11-19 21:59     ` Andy Lutomirski
2015-11-19 23:38     ` David Woodhouse
2015-11-19 23:38       ` David Woodhouse
2015-11-20  2:56       ` Benjamin Herrenschmidt
2015-11-20  2:56         ` Benjamin Herrenschmidt
2015-11-20  8:34         ` Michael S. Tsirkin
2015-11-20  8:34         ` Michael S. Tsirkin
2015-11-20  8:21       ` Michael S. Tsirkin
2015-11-20  8:21         ` Michael S. Tsirkin
2015-11-22 15:58         ` David Woodhouse
2015-11-22 15:58         ` David Woodhouse
2015-11-22 21:52           ` Michael S. Tsirkin
2015-11-22 21:52           ` Michael S. Tsirkin
2015-11-22 22:21             ` David Woodhouse
2015-11-22 22:21               ` David Woodhouse
2015-11-23  7:56               ` Michael S. Tsirkin
2015-11-23  7:56                 ` Michael S. Tsirkin
2015-11-22 22:21             ` David Woodhouse
2015-11-22 22:21               ` David Woodhouse
2015-11-20  6:56     ` Michael S. Tsirkin
2015-11-20  6:56       ` Michael S. Tsirkin
2015-11-20  7:47       ` Michael S. Tsirkin
2015-11-20  7:47         ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2015-10-28  6:38 Andy Lutomirski

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=1446224098.25261.15.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=hch@lst.de \
    --cc=jroedel@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=sebott@linux.vnet.ibm.com \
    --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.