All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
	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: Sun, 08 Nov 2015 12:00:33 +0000	[thread overview]
Message-ID: <1446984033.81031.9.camel@infradead.org> (raw)
In-Reply-To: <20151108120627-mutt-send-email-mst@redhat.com>

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

On Sun, 2015-11-08 at 12:37 +0200, Michael S. Tsirkin wrote:
> On Thu, Oct 29, 2015 at 05:18:56PM +0100, David Woodhouse wrote:
> > On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote:
> > > 
> > > But you trust your hypervisor (you have no choice anyway),
> > > and you don't want the overhead of tweaking IOMMU
> > > on data path for virtio. Thus iommu=on is out too.
> > 
> > That's not at all special for virtio or guest VMs. Even with real
> > hardware, we might want performance from *some* devices, and security
> > from others. See the DMA_ATTR_IOMMU_BYPASS which is currently being
> > discussed.
> 
> Right. So let's wait for that discussion to play out?

That discussion is purely about a requested optimisation. This one is
about correctness.

> > But of course the easy answer in *your* case it just to ask the
> > hypervisor not to put the virtio devices behind an IOMMU at all. Which
> > we were planning to remain the default behaviour.
> 
> One can't do this for x86 ATM, can one?

The converse is true, in fact — currently, there's no way to tell 
qemu-system-x86 that you *do* want it to put the virtio devices behind
the emulated IOMMU, as it has no support for that.

Which is a bit sad really, since the DMAR table that qemu advertises to
the guest does *tell* the guest that the virtio devices are behind the
emulated IOMMU.

In the short term, we'll be fixing the DMAR table, and still not
actually making it possible to put the virtio devices behind the
emulated IOMMU.

In the fullness of time, however, we *will* be fixing the qemu IOMMU
code so that it can translate for virtio devices — and for assigned
physical devices, which I believe are also broken at the moment when
qemu emulates an IOMMU.

> > In all cases, the DMA API shall do the right thing.
> 
> I have no problem with that. For example, can we teach
> the DMA API on intel x86 to use PT for virtio by default?
> That would allow merging Andy's patches with
> full compatibility with old guests and hosts.

A quirk so that we *notice* the bug in the existing qemu DMAR table,
and disbelieve what it says about the virtio devices?

Alternatively, we could just recognise that the emulated IOMMU support
in qemu is an experimental feature and doesn't work right, yet. Are
people really using it in anger?

If we do want to do a quirk, then we should make it get it right for
assigned devices too.

To start with, do you want to try to express the criteria for "the DMAR
table lies and <this> device is actually untranslated" in a form of
prose which could reasonably be translated into code?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


[-- 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>
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>,
	Andy Lutomirski <luto@amacapital.net>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff
Date: Sun, 08 Nov 2015 12:00:33 +0000	[thread overview]
Message-ID: <1446984033.81031.9.camel@infradead.org> (raw)
In-Reply-To: <20151108120627-mutt-send-email-mst@redhat.com>


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

On Sun, 2015-11-08 at 12:37 +0200, Michael S. Tsirkin wrote:
> On Thu, Oct 29, 2015 at 05:18:56PM +0100, David Woodhouse wrote:
> > On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote:
> > > 
> > > But you trust your hypervisor (you have no choice anyway),
> > > and you don't want the overhead of tweaking IOMMU
> > > on data path for virtio. Thus iommu=on is out too.
> > 
> > That's not at all special for virtio or guest VMs. Even with real
> > hardware, we might want performance from *some* devices, and security
> > from others. See the DMA_ATTR_IOMMU_BYPASS which is currently being
> > discussed.
> 
> Right. So let's wait for that discussion to play out?

That discussion is purely about a requested optimisation. This one is
about correctness.

> > But of course the easy answer in *your* case it just to ask the
> > hypervisor not to put the virtio devices behind an IOMMU at all. Which
> > we were planning to remain the default behaviour.
> 
> One can't do this for x86 ATM, can one?

The converse is true, in fact — currently, there's no way to tell 
qemu-system-x86 that you *do* want it to put the virtio devices behind
the emulated IOMMU, as it has no support for that.

Which is a bit sad really, since the DMAR table that qemu advertises to
the guest does *tell* the guest that the virtio devices are behind the
emulated IOMMU.

In the short term, we'll be fixing the DMAR table, and still not
actually making it possible to put the virtio devices behind the
emulated IOMMU.

In the fullness of time, however, we *will* be fixing the qemu IOMMU
code so that it can translate for virtio devices — and for assigned
physical devices, which I believe are also broken at the moment when
qemu emulates an IOMMU.

> > In all cases, the DMA API shall do the right thing.
> 
> I have no problem with that. For example, can we teach
> the DMA API on intel x86 to use PT for virtio by default?
> That would allow merging Andy's patches with
> full compatibility with old guests and hosts.

A quirk so that we *notice* the bug in the existing qemu DMAR table,
and disbelieve what it says about the virtio devices?

Alternatively, we could just recognise that the emulated IOMMU support
in qemu is an experimental feature and doesn't work right, yet. Are
people really using it in anger?

If we do want to do a quirk, then we should make it get it right for
assigned devices too.

To start with, do you want to try to express the criteria for "the DMAR
table lies and <this> device is actually untranslated" in a form of
prose which could reasonably be translated into code?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


[-- 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-11-08 12:00 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 [this message]
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
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=1446984033.81031.9.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.