Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752696AbcD1OfA (ORCPT ); Thu, 28 Apr 2016 10:35:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33076 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751094AbcD1Oe7 (ORCPT ); Thu, 28 Apr 2016 10:34:59 -0400 Date: Thu, 28 Apr 2016 17:34:51 +0300 From: "Michael S. Tsirkin" To: David Woodhouse Cc: Joerg Roedel , Kevin Wolf , Wei Liu , Andy Lutomirski , qemu-block@nongnu.org, Christian Borntraeger , Jason Wang , Stefano Stabellini , qemu-devel@nongnu.org, peterx@redhat.com, linux-kernel@vger.kernel.org, Amit Shah , iommu@lists.linux-foundation.org, Stefan Hajnoczi , kvm@vger.kernel.org, cornelia.huck@de.ibm.com, pbonzini@redhat.com, virtualization@lists.linux-foundation.org, Anthony PERARD Subject: Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api Message-ID: <20160428172039-mutt-send-email-mst@redhat.com> References: <20160421135416.GE11775@citrix.com> <1461759501.118304.149.camel@infradead.org> <20160427153345-mutt-send-email-mst@redhat.com> <20160427142331.GH17926@8bytes.org> <20160427172630-mutt-send-email-mst@redhat.com> <20160427145632.GI17926@8bytes.org> <20160427180007-mutt-send-email-mst@redhat.com> <1461770135.118304.152.camel@infradead.org> <20160427211635-mutt-send-email-mst@redhat.com> <1461784617.118304.181.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461784617.118304.181.camel@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1774 Lines: 53 On Wed, Apr 27, 2016 at 08:16:57PM +0100, David Woodhouse wrote: > On Wed, 2016-04-27 at 21:17 +0300, Michael S. Tsirkin wrote: > > > > > Because it's a dirty hack in the *wrong* place. > > > > No one came up with a better one so far :( > > Seriously? > > Take a look at drivers/iommu/intel-iommu.c. It has quirks for all kinds > of shitty devices that have to be put in passthrough mode or otherwise > excluded. I see work-arounds for broken IOMMUs but not for individual devices. Could you point me to a more specific example? > We don't actually *need* it for the Intel IOMMU; all we need is for > QEMU to stop lying in its DMAR tables. We need it for legacy QEMU anyway, and it's not easy for QEMU to stop lying about virtio, so we'll need it for a while. I think it's easy for QEMU to stop lying about assigned devices, so we don't need it for non-virtio devices. > We *do* want the same kind of quirks in the relevant POWER and ARM > IOMMU code in the kernel. Do that (hell, a simple quirk for all virtio > devices will suffice, but NOT in the virtio driver Sure - that works. It does not have to be in the driver. >) at the same moment > you fix the virtio devices to use the DMA API. Job done. > > Some time *later* we can work on *refining* that quirk, and a way for > QEMU to tell the guest (via something generic like fwcfg, maybe) that > some devices are and aren't translated. I don't see why how fwcfg can work here. It's a static thing, devices can come and go with hotplug. > Actually, I'm about to look at moving dma_ops into struct device and > cleaning up the way we detect which IOMMU is attached, at device > instantiation time. Perhaps I can shove the virtio-exception quirk in > there while I'm at it... Sounds good. > -- > dwmw2 >