From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753190AbcGYTNL (ORCPT ); Mon, 25 Jul 2016 15:13:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38942 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752384AbcGYTNI (ORCPT ); Mon, 25 Jul 2016 15:13:08 -0400 Date: Mon, 25 Jul 2016 22:13:05 +0300 From: "Michael S. Tsirkin" To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH v3] virtio: new feature to detect IOMMU device quirk Message-ID: <20160725214322-mutt-send-email-mst@kernel.org> References: <20160719053823-mutt-send-email-mst@redhat.com> <20160725075009.GA25638@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160725075009.GA25638@infradead.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 25 Jul 2016 19:13:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 25, 2016 at 12:50:09AM -0700, Christoph Hellwig wrote: > On Tue, Jul 19, 2016 at 05:38:23AM +0300, Michael S. Tsirkin wrote: > > > > On other systems, including SPARC and PPC64, virtio-pci devices are > > enumerated as though they are behind an IOMMU, but the virtio host > > ignores the IOMMU, so we must either pretend that the IOMMU isn't > > there or somehow map everything as the identity. > > > > Add a feature bit to detect that quirk: VIRTIO_F_IOMMU_PLATFORM. > > > > Any device with this feature bit set to 0 needs a quirk and has to be > > passed physical addresses (as opposed to bus addresses) even though > > the device is behind an IOMMU. > > This is the wrong way around. Well given there are tons of quirky devices out there and they have this bit set to 0, I don't think we can change this. New devices will have it set to 1. > > Note: it has to be a per-device quirk because for example, there could > > be a mix of passed-through and virtual virtio devices. As another > > example, some devices could be implemented by an out of process > > hypervisor backend (in case of qemu vhost, or vhost-user) and so support > > for an IOMMU needs to be coded up separately. > > > > It would be cleanest to handle this in IOMMU core code, but that needs > > per-device DMA ops. While we are waiting for that to be implemented, use > > a work-around in virtio core. > > > > Signed-off-by: Michael S. Tsirkin > > --- > > > > wanted to use per-device dma ops but that does not > > seem to be ready. So let's put this in virtio > > code for now, and move when it becomes possible. > > So work on making it ready. We're close to there, and given that > virtio needs it, finish it off. We now have everyone using the > operation vectors for DMA, so the only thing you need is a dma_ops > pointer in struct device initialized to what get_dma_ops returns. And then pci_dma_configure would have a quirk to set that for legacy virtio devices? -- MST