All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	sparclinux@vger.kernel.org, Joerg Roedel <jroedel@suse.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Christoph Hellwig <hch@lst.de>, 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>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion
Date: Tue, 10 Nov 2015 21:37:54 +1100	[thread overview]
Message-ID: <1447151874.31884.82.camel@kernel.crashing.org> (raw)
In-Reply-To: <CALCETrVPQc04Ah7FXcRMb4RhpUJ1WPCoC_4dbacB8a+u5XpmwA@mail.gmail.com>

On Mon, 2015-11-09 at 21:35 -0800, Andy Lutomirski wrote:
> 
> We could do it the other way around: on powerpc, if a PCI device is in
> that range and doesn't have the "bypass" property at all, then it's
> assumed to bypass the IOMMU.  This means that everything that
> currently works continues working.  If someone builds a physical
> virtio device or uses another system in PCIe target mode speaking
> virtio, then it won't work until they upgrade their firmware to set
> bypass=0.  Meanwhile everyone using hypothetical new QEMU also gets
> bypass=0 and no ambiguity.
>
> vfio will presumably notice the bypass and correctly refuse to map any
> current virtio devices.
> 
> Would that work?

That would be extremely strange from a platform perspective. Any device
in that vendor/device range would bypass the iommu unless some new
property "actually-works-like-a-real-pci-device" happens to exist in
the device-tree, which we would then need to define somewhere and
handle accross at least 3 different platforms who get their device-tree 
from widly different places.

Also if tomorrow I create a PCI device that implements virtio-net and
put it in a machine running IBM proprietary firmware (or Apple's or
Sun's), it won't have that property...

This is not hypothetical. People are using virtio to do point-to-point
communication between machines via PCIe today.

Cheers,
Ben.



WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Joerg Roedel <jroedel@suse.de>, KVM <kvm@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Andy Lutomirski <luto@kernel.org>,
	sparclinux@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"David S. Miller" <davem@davemloft.net>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion
Date: Tue, 10 Nov 2015 21:37:54 +1100	[thread overview]
Message-ID: <1447151874.31884.82.camel@kernel.crashing.org> (raw)
In-Reply-To: <CALCETrVPQc04Ah7FXcRMb4RhpUJ1WPCoC_4dbacB8a+u5XpmwA@mail.gmail.com>

On Mon, 2015-11-09 at 21:35 -0800, Andy Lutomirski wrote:
> 
> We could do it the other way around: on powerpc, if a PCI device is in
> that range and doesn't have the "bypass" property at all, then it's
> assumed to bypass the IOMMU.  This means that everything that
> currently works continues working.  If someone builds a physical
> virtio device or uses another system in PCIe target mode speaking
> virtio, then it won't work until they upgrade their firmware to set
> bypass=0.  Meanwhile everyone using hypothetical new QEMU also gets
> bypass=0 and no ambiguity.
>
> vfio will presumably notice the bypass and correctly refuse to map any
> current virtio devices.
> 
> Would that work?

That would be extremely strange from a platform perspective. Any device
in that vendor/device range would bypass the iommu unless some new
property "actually-works-like-a-real-pci-device" happens to exist in
the device-tree, which we would then need to define somewhere and
handle accross at least 3 different platforms who get their device-tree 
from widly different places.

Also if tomorrow I create a PCI device that implements virtio-net and
put it in a machine running IBM proprietary firmware (or Apple's or
Sun's), it won't have that property...

This is not hypothetical. People are using virtio to do point-to-point
communication between machines via PCIe today.

Cheers,
Ben.


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

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Joerg Roedel <jroedel@suse.de>, KVM <kvm@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Andy Lutomirski <luto@kernel.org>,
	sparclinux@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"David S. Miller" <davem@davemloft.net>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion
Date: Tue, 10 Nov 2015 10:37:54 +0000	[thread overview]
Message-ID: <1447151874.31884.82.camel@kernel.crashing.org> (raw)
In-Reply-To: <CALCETrVPQc04Ah7FXcRMb4RhpUJ1WPCoC_4dbacB8a+u5XpmwA@mail.gmail.com>

On Mon, 2015-11-09 at 21:35 -0800, Andy Lutomirski wrote:
> 
> We could do it the other way around: on powerpc, if a PCI device is in
> that range and doesn't have the "bypass" property at all, then it's
> assumed to bypass the IOMMU.  This means that everything that
> currently works continues working.  If someone builds a physical
> virtio device or uses another system in PCIe target mode speaking
> virtio, then it won't work until they upgrade their firmware to set
> bypass=0.  Meanwhile everyone using hypothetical new QEMU also gets
> bypass=0 and no ambiguity.
>
> vfio will presumably notice the bypass and correctly refuse to map any
> current virtio devices.
> 
> Would that work?

That would be extremely strange from a platform perspective. Any device
in that vendor/device range would bypass the iommu unless some new
property "actually-works-like-a-real-pci-device" happens to exist in
the device-tree, which we would then need to define somewhere and
handle accross at least 3 different platforms who get their device-tree 
from widly different places.

Also if tomorrow I create a PCI device that implements virtio-net and
put it in a machine running IBM proprietary firmware (or Apple's or
Sun's), it won't have that property...

This is not hypothetical. People are using virtio to do point-to-point
communication between machines via PCIe today.

Cheers,
Ben.



  reply	other threads:[~2015-11-10 10:38 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30  1:09 [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 1/6] virtio-net: Stop doing DMA from the stack Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30 13:55   ` Christian Borntraeger
2015-10-30 13:55     ` Christian Borntraeger
2015-10-31  5:02     ` Andy Lutomirski
2015-10-31  5:02       ` Andy Lutomirski
2015-10-31  5:02       ` Andy Lutomirski
2015-10-30 13:55   ` Christian Borntraeger
2015-10-30  1:09 ` [PATCH v4 2/6] virtio_ring: Support DMA APIs Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30 12:01   ` Cornelia Huck
2015-10-30 12:01     ` Cornelia Huck
2015-10-30 12:01     ` Cornelia Huck
2015-10-30 12:05     ` Christian Borntraeger
2015-10-30 12:05       ` Christian Borntraeger
2015-10-30 12:05       ` Christian Borntraeger
2015-10-30 18:51       ` Andy Lutomirski
2015-10-30 18:51       ` Andy Lutomirski
2015-10-30 18:51         ` Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 3/6] virtio_pci: Use the DMA API Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 4/6] virtio: Add improved queue allocation API Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 5/6] virtio_mmio: Use the DMA API Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 6/6] virtio_pci: " Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:17 ` [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski
2015-10-30  1:17   ` Andy Lutomirski
2015-10-30  1:17   ` Andy Lutomirski
2015-10-30  9:57 ` Christian Borntraeger
2015-10-30  9:57   ` Christian Borntraeger
2015-10-30  9:57 ` Christian Borntraeger
2015-11-09 12:15 ` Michael S. Tsirkin
2015-11-09 12:15   ` Michael S. Tsirkin
2015-11-09 12:15   ` Michael S. Tsirkin
2015-11-09 12:27   ` Paolo Bonzini
2015-11-09 12:27     ` Paolo Bonzini
2015-11-09 12:27   ` Paolo Bonzini
2015-11-09 22:58   ` Benjamin Herrenschmidt
2015-11-09 22:58     ` Benjamin Herrenschmidt
2015-11-09 22:58     ` Benjamin Herrenschmidt
2015-11-10  0:46     ` Andy Lutomirski
2015-11-10  0:46       ` Andy Lutomirski
2015-11-10  0:46       ` Andy Lutomirski
2015-11-10  2:04       ` Benjamin Herrenschmidt
2015-11-10  2:04         ` Benjamin Herrenschmidt
2015-11-10  2:04         ` Benjamin Herrenschmidt
2015-11-10  2:18         ` Andy Lutomirski
2015-11-10  2:18         ` Andy Lutomirski
2015-11-10  2:18           ` Andy Lutomirski
2015-11-10  5:26           ` Benjamin Herrenschmidt
2015-11-10  5:26             ` Benjamin Herrenschmidt
2015-11-10  5:26             ` Benjamin Herrenschmidt
2015-11-10  5:33             ` Andy Lutomirski
2015-11-10  5:33             ` Andy Lutomirski
2015-11-10  5:33               ` Andy Lutomirski
2015-11-10  5:28           ` Benjamin Herrenschmidt
2015-11-10  5:28             ` Benjamin Herrenschmidt
2015-11-10  5:28             ` Benjamin Herrenschmidt
2015-11-10  5:35             ` Andy Lutomirski
2015-11-10  5:35             ` Andy Lutomirski
2015-11-10  5:35               ` Andy Lutomirski
2015-11-10 10:37               ` Benjamin Herrenschmidt [this message]
2015-11-10 10:37                 ` Benjamin Herrenschmidt
2015-11-10 10:37                 ` Benjamin Herrenschmidt
2015-11-10 12:43                 ` Michael S. Tsirkin
2015-11-10 12:43                   ` Michael S. Tsirkin
2015-11-10 12:43                   ` Michael S. Tsirkin
2015-11-10 19:37                   ` Benjamin Herrenschmidt
2015-11-10 19:37                     ` Benjamin Herrenschmidt
2015-11-10 19:37                     ` Benjamin Herrenschmidt
2015-11-10 12:43                 ` Michael S. Tsirkin
2015-11-10 18:54                 ` Andy Lutomirski
2015-11-10 18:54                   ` Andy Lutomirski
2015-11-10 18:54                   ` Andy Lutomirski
2015-11-10 22:27                   ` Benjamin Herrenschmidt
2015-11-10 22:27                     ` Benjamin Herrenschmidt
2015-11-10 22:27                     ` Benjamin Herrenschmidt
2015-11-10 23:44                     ` Andy Lutomirski
2015-11-10 23:44                     ` Andy Lutomirski
2015-11-10 23:44                       ` Andy Lutomirski
2015-11-11  0:44                       ` Benjamin Herrenschmidt
2015-11-11  0:44                         ` Benjamin Herrenschmidt
2015-11-11  0:44                         ` Benjamin Herrenschmidt
2015-11-11  4:46                         ` Andy Lutomirski
2015-11-11  4:46                           ` Andy Lutomirski
2015-11-11  4:46                           ` Andy Lutomirski
2015-11-11  5:08                           ` Benjamin Herrenschmidt
2015-11-11  5:08                             ` Benjamin Herrenschmidt
2015-11-11  5:08                             ` Benjamin Herrenschmidt
2015-11-10  7:28           ` Jan Kiszka
2015-11-10  7:28             ` Jan Kiszka
2015-11-10  7:28             ` Jan Kiszka
2015-11-10  7:28             ` Jan Kiszka
2015-11-10  9:45         ` Knut Omang
2015-11-10  9:45         ` Knut Omang
2015-11-10  9:45           ` Knut Omang
2015-11-10 10:26           ` Benjamin Herrenschmidt
2015-11-10 10:26             ` Benjamin Herrenschmidt
2015-11-10 10:26             ` Benjamin Herrenschmidt
2015-11-10 10:27         ` Joerg Roedel
2015-11-10 10:27           ` Joerg Roedel
2015-11-10 10:27           ` Joerg Roedel
2015-11-10 19:36           ` Benjamin Herrenschmidt
2015-11-10 19:36             ` Benjamin Herrenschmidt
2015-11-10 19:36             ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2015-10-30  1:09 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=1447151874.31884.82.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=davem@davemloft.net \
    --cc=dwmw2@infradead.org \
    --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=sparclinux@vger.kernel.org \
    --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.