Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965256AbbLOMOl (ORCPT ); Tue, 15 Dec 2015 07:14:41 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:19494 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965086AbbLOMOi (ORCPT ); Tue, 15 Dec 2015 07:14:38 -0500 X-IronPort-AV: E=Sophos;i="5.20,431,1444694400"; d="scan'208";a="325138365" Date: Tue, 15 Dec 2015 12:13:58 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Andy Lutomirski CC: "Michael S. Tsirkin" , David Vrabel , Stefano Stabellini , "xen-devel@lists.xenproject.org" , "linux-kernel@vger.kernel.org" , Linux Virtualization , Benjamin Herrenschmidt Subject: Re: [Xen-devel] [PATCH RFC 0/3] Xen on Virtio In-Reply-To: Message-ID: References: <566ECB65.3060509@citrix.com> <20151214161037-mutt-send-email-mst@redhat.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3945 Lines: 79 On Mon, 14 Dec 2015, Andy Lutomirski wrote: > On Mon, Dec 14, 2015 at 6:12 AM, Michael S. Tsirkin wrote: > > On Mon, Dec 14, 2015 at 02:00:05PM +0000, David Vrabel wrote: > >> On 07/12/15 16:19, Stefano Stabellini wrote: > >> > Hi all, > >> > > >> > this patch series introduces support for running Linux on top of Xen > >> > inside a virtual machine with virtio devices (nested virt scenario). > >> > The problem is that Linux virtio drivers use virt_to_phys to get the > >> > guest pseudo-physical addresses to pass to the backend, which doesn't > >> > work as expected on Xen. > >> > > >> > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, > >> > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as > >> > Xen support in Linux provides an implementation of the dma API which > >> > takes care of the additional address conversions. However using the dma > >> > API would increase the complexity of the non-Xen case too. We would also > >> > need to keep track of the physical or virtual address in addition to the > >> > dma address for each vring_desc to be able to free the memory in > >> > detach_buf (see patch #3). > >> > > >> > Instead this series adds few obvious checks to perform address > >> > translations in a couple of key places, without changing non-Xen code > >> > paths. You are welcome to suggest improvements or alternative > >> > implementations. > >> > >> Andy Lutomirski also looked at this. Andy what happened to this work? > >> > >> David > > > > The approach there was to try and convert all virtio to use DMA > > API unconditionally. > > This is reasonable if there's a way for devices to request > > 1:1 mappings individually. > > As that is currently missing, that patchset can not be merged yet. > > > > I still don't understand why *devices* need the ability to request > anything in particular. In current kernels, devices that don't have > an iommu work (and there's no choice about 1:1 or otherwise) and > devices that have an iommu fail spectacularly. With the patches, > devices that don't have an iommu continue to work as long as the DMA > API and/or virtio correctly knows that there's no iommu. Devices that > do have an iommu work fine, albeit slower than would be ideal. In my > book, slower than would be ideal is strictly better than crashing. > > The real issue is *detecting* whether there's an iommu, and the string > of bugs in that area (buggy QEMU for the Q35 thing and complete lack > of a solution for PPC and SPARC is indeed a problem). > > I think that we could apply the series ending here: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=virtio_dma&id=ad9d43052da44ce18363c02ea597dde01eeee11b > > and the only regression (performance or functionality) would be that > the buggy Q35 iommu configuration would stop working until someone > fixed it in QEMU. That should be okay -- it's explicitly > experimental. (Xen works with that series applied.) (Actually, > there might be a slight performance regression on PPC due to extra > unused mappings being created. It would be straightforward to hack > around that in one of several ways.) > > Am I missing something? Your changes look plausible and if they fix Xen on virtio I am happy with them. I didn't choose the DMA API approach because, although it looks cleaner, I acknowledge that is a bit invasive. I suggest that the virtio maintainers consider one of the two approaches for inclusion because they fix a real issue. If you would rather avoid the DMA API, then I would be happy to work with you to evolve my current series in a direction of your liking. Please advise on how to proceed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/