Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1815684imu; Thu, 17 Jan 2019 03:48:45 -0800 (PST) X-Google-Smtp-Source: ALg8bN7RM5fntl3lz7jxHZHCpE2Q0jTrquOv4QpCkWOXrDngEIZYUFW04Hte/4G+mKy+WWK9Jd+2 X-Received: by 2002:a62:5793:: with SMTP id i19mr14674585pfj.49.1547725725165; Thu, 17 Jan 2019 03:48:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547725725; cv=none; d=google.com; s=arc-20160816; b=SVyVjAAe5VPj0iePjH2jNDuwdXFn2/TdI1R6D9MzxR9+ByNTBZh3OKbiHpIYbSQrwD iZv1fbsac/oWqhZKtFsmwb54fOzCQZfkqDgCR9PLFqWRYTXGKxTfN2ev97lMOvm8lOdp LAhltNuYpJEqKTJp60imfhDGfETRBNkVH/OM15jNhm7BYePOkhGD5OqocDWx20b92En1 OgrUifGqgsm9KHY1Pe/jyDy9Yyn7zrktZVouOFq9JMUxiF2qbd5h4a9F0QHvVY3UadqG i5XsA9CXHmv0Ys7hGSHbV7S0EdxdvwdqBtHkJzZ+vgYu4olZzgf6zg4LBkZHsFuBroFi ZMTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=vPs532lz24/5CGlt9UmXlikH/2eCv1vVuAmUvZ0QDQ4=; b=W+VM3m/1KSH3KxKOPsSA8cFWmsudSdQLSPQAe1IEydwffdWqkNbScJ5qZTTRNO4TuV rG6M/Z8hN44w8+UcaSECd8qg6deVy8wMbyyXFVIEcgP2TxfCuyWUVZ3SDwVUxSmfI1QH 3jRzKg2MRSBw7zJ2r3Q2Gqp34l/XlqqcwnVI0qYKZJfRys0ylXcn2gHrSk0gd1uYDSpY lIcpX/VraiFNzAk/szzR5QiOq5KPx7GB3a451HUi8gPHhBy/B89lQzc96g/lkzbKzoyO YPpqO2PpBIU+0neBEkVlyRuCck23LTfKGVdEGatnKDH6WAWVF5dfvcf28NHX1r7pgI4r mlsw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g124si1309865pgc.568.2019.01.17.03.48.30; Thu, 17 Jan 2019 03:48:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728500AbfAQKyr (ORCPT + 99 others); Thu, 17 Jan 2019 05:54:47 -0500 Received: from bastet.se.axis.com ([195.60.68.11]:44098 "EHLO bastet.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725990AbfAQKyr (ORCPT ); Thu, 17 Jan 2019 05:54:47 -0500 Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id A801B18582; Thu, 17 Jan 2019 11:54:43 +0100 (CET) X-Axis-User: NO X-Axis-NonUser: YES X-Virus-Scanned: Debian amavisd-new at bastet.se.axis.com Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id MOgDnb2tF8EW; Thu, 17 Jan 2019 11:54:42 +0100 (CET) Received: from boulder03.se.axis.com (boulder03.se.axis.com [10.0.8.17]) by bastet.se.axis.com (Postfix) with ESMTPS id 4C9251857F; Thu, 17 Jan 2019 11:54:42 +0100 (CET) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0C4681E081; Thu, 17 Jan 2019 11:54:42 +0100 (CET) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F30CF1E080; Thu, 17 Jan 2019 11:54:41 +0100 (CET) Received: from seth.se.axis.com (unknown [10.0.2.172]) by boulder03.se.axis.com (Postfix) with ESMTP; Thu, 17 Jan 2019 11:54:41 +0100 (CET) Received: from lnxartpec.se.axis.com (lnxartpec.se.axis.com [10.88.4.9]) by seth.se.axis.com (Postfix) with ESMTP id E4E0E1885; Thu, 17 Jan 2019 11:54:41 +0100 (CET) Received: by lnxartpec.se.axis.com (Postfix, from userid 10564) id E16A380B46; Thu, 17 Jan 2019 11:54:41 +0100 (CET) Date: Thu, 17 Jan 2019 11:54:41 +0100 From: Vincent Whitchurch To: Arnd Bergmann Cc: sudeep.dutt@intel.com, ashutosh.dixit@intel.com, gregkh , Linux Kernel Mailing List , Kishon Vijay Abraham I , Lorenzo Pieralisi , linux-pci , linux-ntb@googlegroups.com, Jon Mason , Dave Jiang , Allen Hubbe Subject: Re: [PATCH 0/8] Virtio-over-PCIe on non-MIC Message-ID: <20190117105441.eqediwlekofp2srg@axis.com> References: <20190116163253.23780-1-vincent.whitchurch@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-TM-AS-GCONF: 00 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 16, 2019 at 06:07:53PM +0100, Arnd Bergmann wrote: > On Wed, Jan 16, 2019 at 5:33 PM Vincent Whitchurch wrote: > > The Virtio-over-PCIe framework living under drivers/misc/mic/vop implements a > > generic framework to use virtio between two Linux systems, given shared memory > > and a couple of interrupts. It does not actually require the Intel MIC > > hardware, x86-64, or even PCIe for that matter. This patch series makes it > > buildable on more systems and adds a loopback driver to test it without special > > hardware. > > > > Note that I don't have access to Intel MIC hardware so some testing of the > > patchset (especially the patch "vop: Use consistent DMA") on that platform > > would be appreciated, to ensure that the series does not break anything there. > > I think we need to take a step back though and discuss what combinations > we actually do want to support. I have not actually read the whole mic/vop > driver, so I don't know if this would be a good fit as a generic interface -- > it may or may not be, and any other input would be helpful. The MIC driver as a whole is uninteresting as a generic interface since it is quite tied to the Intel hardware. The VOP parts though are logically separated and have no relation to that hardware, even if the ioctls are called MIC_VIRTIO_*. The samples/mic/mpssd/mpssd.c code handles both the boot of the MIC (sysfs) and the VOP parts (ioctls). > Aside from that, I should note that we have two related subsystems > in the kernel: the PCIe endpoint subsystem maintained by Kishon and > Lorenzo, and the NTB subsystem maintained by Jon, Dave and Allen. > > In order to properly support virtio over PCIe, I would hope we can come > up with a user space interface that looks the same way for configuring > virtio drivers in mic, pcie-endpoint and ntb, if at all possible. Have > you looked at those two subsystems? pcie-endpoint is a generic framework that allows Linux to act as an endpoint and set up the BARs, etc. mic appears to have Intel MIC-specific code for this (pre-dating pcie-endpoint) but this is separate from the vop code. pcie-endpoint and vop do not have overlapping functionality and can be used together. I'm not familiar with NTB, but from a quick look it seems to be tied to special hardware, and I don't see any virtio-related code there. A vop backend for NTB-backend would presumably work to allow virtio functionality there.