From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752070AbbKJSzF (ORCPT ); Tue, 10 Nov 2015 13:55:05 -0500 Received: from mail-oi0-f41.google.com ([209.85.218.41]:36617 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751890AbbKJSy5 (ORCPT ); Tue, 10 Nov 2015 13:54:57 -0500 MIME-Version: 1.0 In-Reply-To: <1447151874.31884.82.camel@kernel.crashing.org> References: <20151109133624-mutt-send-email-mst@redhat.com> <1447109937.31884.42.camel@kernel.crashing.org> <1447121076.31884.61.camel@kernel.crashing.org> <1447133316.31884.67.camel@kernel.crashing.org> <1447151874.31884.82.camel@kernel.crashing.org> From: Andy Lutomirski Date: Tue, 10 Nov 2015 10:54:37 -0800 Message-ID: Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion To: Benjamin Herrenschmidt Cc: Christian Borntraeger , Paolo Bonzini , David Woodhouse , Martin Schwidefsky , "Michael S. Tsirkin" , Sebastian Ott , "David S. Miller" , linux-s390 , Cornelia Huck , Joerg Roedel , KVM , Christoph Hellwig , Linux Virtualization , "linux-kernel@vger.kernel.org" , sparclinux@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Nov 10, 2015 2:38 AM, "Benjamin Herrenschmidt" wrote: > > 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. Does that work on powerpc on existing kernels? Anyway, here's another crazy idea: make the quirk assume that the IOMMU is bypasses if and only if the weak barriers bit is set on systems that are missing the new DT binding. --Andy > > Cheers, > Ben. > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion Date: Tue, 10 Nov 2015 10:54:37 -0800 Message-ID: References: <20151109133624-mutt-send-email-mst@redhat.com> <1447109937.31884.42.camel@kernel.crashing.org> <1447121076.31884.61.camel@kernel.crashing.org> <1447133316.31884.67.camel@kernel.crashing.org> <1447151874.31884.82.camel@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1447151874.31884.82.camel@kernel.crashing.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Archive: List-Post: To: Benjamin Herrenschmidt Cc: linux-s390 , sparclinux@vger.kernel.org, KVM , "Michael S. Tsirkin" , Sebastian Ott , "linux-kernel@vger.kernel.org" , Christoph Hellwig , Christian Borntraeger , Joerg Roedel , Martin Schwidefsky , Paolo Bonzini , Linux Virtualization , David Woodhouse , "David S. Miller" List-ID: On Nov 10, 2015 2:38 AM, "Benjamin Herrenschmidt" wrote: > > 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. Does that work on powerpc on existing kernels? Anyway, here's another crazy idea: make the quirk assume that the IOMMU is bypasses if and only if the weak barriers bit is set on systems that are missing the new DT binding. --Andy > > Cheers, > Ben. > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Date: Tue, 10 Nov 2015 18:54:37 +0000 Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion Message-Id: List-Id: References: <20151109133624-mutt-send-email-mst@redhat.com> <1447109937.31884.42.camel@kernel.crashing.org> <1447121076.31884.61.camel@kernel.crashing.org> <1447133316.31884.67.camel@kernel.crashing.org> <1447151874.31884.82.camel@kernel.crashing.org> In-Reply-To: <1447151874.31884.82.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Benjamin Herrenschmidt Cc: linux-s390 , sparclinux@vger.kernel.org, KVM , "Michael S. Tsirkin" , Sebastian Ott , "linux-kernel@vger.kernel.org" , Christoph Hellwig , Christian Borntraeger , Joerg Roedel , Martin Schwidefsky , Paolo Bonzini , Linux Virtualization , David Woodhouse , "David S. Miller" On Nov 10, 2015 2:38 AM, "Benjamin Herrenschmidt" wrote: > > 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. Does that work on powerpc on existing kernels? Anyway, here's another crazy idea: make the quirk assume that the IOMMU is bypasses if and only if the weak barriers bit is set on systems that are missing the new DT binding. --Andy > > Cheers, > Ben. > >