Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752186AbcDRPaw (ORCPT ); Mon, 18 Apr 2016 11:30:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40215 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751552AbcDRPau (ORCPT ); Mon, 18 Apr 2016 11:30:50 -0400 Date: Mon, 18 Apr 2016 18:30:41 +0300 From: "Michael S. Tsirkin" To: David Woodhouse Cc: qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, peterx@redhat.com, cornelia.huck@de.ibm.com, Stefan Hajnoczi , Kevin Wolf , Amit Shah , qemu-block@nongnu.org, Jason Wang , Alex Williamson , Andy Lutomirski , Christian Borntraeger , Wei Liu , virtualization@lists.linux-foundation.org, kvm@vger.kernel.org Subject: Re: [PATCH RFC] fixup! virtio: convert to use DMA api Message-ID: <20160418182320-mutt-send-email-mst@redhat.com> References: <1460979793-6621-1-git-send-email-mst@redhat.com> <1460980717.12793.43.camel@infradead.org> <20160418160731-mutt-send-email-mst@redhat.com> <1460988232.22654.7.camel@infradead.org> <20160418170534-mutt-send-email-mst@redhat.com> <1460992923.3765.8.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1460992923.3765.8.camel@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2415 Lines: 66 On Mon, Apr 18, 2016 at 11:22:03AM -0400, David Woodhouse wrote: > On Mon, 2016-04-18 at 17:23 +0300, Michael S. Tsirkin wrote: > > > > This patch doesn't change DMAR tables, it creates a way for virtio > > device to tell guest "I obey what DMAR tables tell you, you can stop > > doing hacks". > > > > And as PPC guys seem adamant that platform tools there are no good for > > that purpose, there's another bit that says "ignore what platform tells > > you, I'm not a real device - I'm part of hypervisor and I bypass the > > IOMMU". > > ... > > +/* Request IOMMU passthrough (if available) > + * Without VIRTIO_F_IOMMU_PLATFORM: bypass the IOMMU even if enabled. > + * With VIRTIO_F_IOMMU_PLATFORM: suggest disabling IOMMU. > + */ > +#define VIRTIO_F_IOMMU_PASSTHROUGH     33 > + > +/* Do not bypass the IOMMU (if configured) */ > +#define VIRTIO_F_IOMMU_PLATFORM                34 > > OK... let's see if I can reconcile those descriptions coherently. > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > its own operating system's IOMMU code is expected to be broken, and > that the virtio driver should eschew the DMA API? No - it tells guest that e.g. the ACPI tables (or whatever the equivalent is) do not match reality with respect to this device since IOMMU is ignored by hypervisor. Hypervisor has no idea what does guest IOMMU code do - hopefully it is not actually broken. > And that the guest OS > cannot further assign the affected device to any of *its* nested > guests? Not that the broken IOMMU code in said guest OS will know the > latter, of course. > > With VIRTIO_F_IOMMU_PLATFORM set, VIRTIO_F_IOMMU_PASSTHROUGH is just a > *hint*, suggesting that the guest OS should *request* a passthrough > mapping from the IOMMU? Right. But it'll work correctly if you don't. > Via a driver←→IOMMU API which doesn't yet exist > in Linux, since we only have 'iommu=pt' on the command line for that? > > And having *neither* of those bits sets is the status quo, which means > that your OS code might well be broken and need you to eschew the DMA > API, but maybe not. The status quo is that that the IOMMU might well be bypassed and then you need to program physical addresses into the device, but maybe not. If DMA API does not give you physical addresses, you need to bypass it, but hypervisor does not know or care. > > --  > dwmw2 > >