From patchwork Fri Nov 22 10:49:47 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jean-Philippe Brucker X-Patchwork-Id: 179987 Delivered-To: patch@linaro.org Received: by 2002:a92:38d5:0:0:0:0:0 with SMTP id g82csp34021ilf; Fri, 22 Nov 2019 02:50:57 -0800 (PST) X-Google-Smtp-Source: APXvYqzXU+iCBBUfEbEMIswgcJP+Tee9gZB96V7Kb3giXBXzvJ0mIEuAsn+wJsOppKVq2o/ma7ia X-Received: by 2002:a17:906:7251:: with SMTP id n17mr21723035ejk.329.1574419857401; Fri, 22 Nov 2019 02:50:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574419857; cv=none; d=google.com; s=arc-20160816; b=j4xZIeqO0A8yQpQw0avRbifMjW85/rZDMSaukZpdirEhwQ8G2JH04bXV4zZnQDNMPi 6A3hWaL/yFnt8YrmQeU3earqWPL9GDd/vUdd3P6cbEt/HYYsjql8BbrOwdeLfEI/hFTL ns9ADcWGKZNLyjt7wMHcbcljLcNyllOAU8pKdYP0D7LvCBE8PYhpbGSJMIrNgpU0Z1fQ A/nNt7DqpYfiyrS74sYN50aYAJzpF2WImDwoq+RRUD2n2FHTmj/VPAZi+1yFTDDRucvU HPv6KNxNddN3+YvrWulD6kqGxcrcRRzp0Ur0ydBR6KKLshgiXedwcplMy5jNhXkgTd4v cxyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=TVZC8O5GuUsgdVDCzcN2CqTy4L8wnnx0IKWd5NiFgCs=; b=g1F7HELULK5gOlhPM4tOLIKtzod8ai0K8r8wbRJhk4IkDUb/1Cmfh8/11GqfiEfDoS z3yD1fIQDGy4Nv71PbPX/RTwQOO3SMpC8uD0fdTD+pfTg6y0QRZeZcNUpu8ka268p/R7 HRpSUX/KlLghZGR8snOYiLJZ8rMEHOpKJ6QKSQ47SBA3d5nhxVZGZpE0YYEiXwZMd5Yv 164cmO40PaJRb4tvJ3kN0QAbajDLQUNafH5/OvLvUhACnkYc9kAQ4KRcew8cqBM26KsD jzpbRa0kM39M0c5zGvjfoXHsHKQM2A1zveAbFLbEeEIfcmoTfOWrHf0Fx51iDCeYc/O5 gKhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Q3aBSYS6; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f13si4077479ejc.311.2019.11.22.02.50.56; Fri, 22 Nov 2019 02:50:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Q3aBSYS6; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727702AbfKVKuz (ORCPT + 7 others); Fri, 22 Nov 2019 05:50:55 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:37426 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728776AbfKVKux (ORCPT ); Fri, 22 Nov 2019 05:50:53 -0500 Received: by mail-wr1-f67.google.com with SMTP id t1so8060584wrv.4 for ; Fri, 22 Nov 2019 02:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=TVZC8O5GuUsgdVDCzcN2CqTy4L8wnnx0IKWd5NiFgCs=; b=Q3aBSYS6L0keHFMg9s3YF/O/MS0ZbpfYzXYluOwOpxXbstgAIVmQmrUo3jmGNcrDMZ RRPRqees28PfvdT26W0bPHIpTF934vMZ1mdXqlDToqWtyVfmuX00leXURFV5dfkQ02NJ g8MLLi84nyK+BFemsn5DmX+bFGOhLRD0eyOqDxu7lLUZ9cyS3bFHai1Fg75a75rR5dmc HAtSQb2nq4jX33aT5hVPbjbJphW0npRYuRLSvtGKiec4rx5bJjM/h3+QM3a2GsLsz6Wf aE1lZ/Wt3JEJzcp0sPuMjwjNU7ZJsgm+knGVpf9Ib7BC1bjVvZmANR5bEwTu8vWj9Clx OrdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=TVZC8O5GuUsgdVDCzcN2CqTy4L8wnnx0IKWd5NiFgCs=; b=QY1mwB1VQjBLUfRAS34dM35miYryd++1Cwwda6j43db9jsjaRfzuW1Iwelrx0lEb9y UV1cxby2QK8qwOpjtHWyG4v4z4GW/cMoDprNTdvdvXjNOI9jhhtriZTYpuxhDBPIpzt/ X+pSVc/3dXTUg+HYSYcDHiDKeKGgoMPCg/fy9c+DMMcX5X393VuWdZWtN1Qp2hZiQJ9r DWcIBic8Gh1olpPh9sjeGSqBsrmr3D0+IoJE63ZNNvxpZQEHi6+BP5QmEKR1PXru0gi0 HGnYTGdwcQ0VIBM5g3/UBMlPsrRGdeVAMO7JUSD7u+U/n8xntqk4so5bVyoNsojmLxa4 ua0g== X-Gm-Message-State: APjAAAVGH3cAOHQencEI1/Egc+i1pzGNuzS1EdrWHpdFiqtZJuyCtZCJ WPKGUst4uO0pQ1mjklOu4JrpdvpZ/zk= X-Received: by 2002:adf:f688:: with SMTP id v8mr174600wrp.147.1574419850990; Fri, 22 Nov 2019 02:50:50 -0800 (PST) Received: from localhost.localdomain (xdsl-188-155-204-106.adslplus.ch. [188.155.204.106]) by smtp.gmail.com with ESMTPSA id o133sm2088197wmb.4.2019.11.22.02.50.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Nov 2019 02:50:50 -0800 (PST) From: Jean-Philippe Brucker To: linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, virtualization@lists.linux-foundation.org, linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org Cc: rjw@rjwysocki.net, lenb@kernel.org, lorenzo.pieralisi@arm.com, guohanjun@huawei.com, sudeep.holla@arm.com, gregkh@linuxfoundation.org, joro@8bytes.org, bhelgaas@google.com, mst@redhat.com, jasowang@redhat.com, jacob.jun.pan@intel.com, eric.auger@redhat.com, sebastien.boeuf@intel.com, kevin.tian@intel.com Subject: [RFC 00/13] virtio-iommu on non-devicetree platforms Date: Fri, 22 Nov 2019 11:49:47 +0100 Message-Id: <20191122105000.800410-1-jean-philippe@linaro.org> X-Mailer: git-send-email 2.24.0 MIME-Version: 1.0 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA. It's a solved problem: firmware or hypervisor describes through DT or ACPI tables the device dependencies, and probe of endpoints is deferred until the IOMMU is probed. But: (1) ACPI has one table per vendor (DMAR for Intel, IVRS for AMD and IORT for Arm). From my point of view IORT is easier to extend, since we just need to introduce a new node type. There are no dependencies to Arm in the Linux IORT driver, so it works well with CONFIG_X86. However, there are concerns about other OS vendors feeling obligated to implement this new node, so Arm proposed introducing another ACPI table, that can wrap any of DMAR, IVRS and IORT to extend it with new virtual nodes. A draft of this VIOT table specification is available at http://jpbrucker.net/virtio-iommu/viot/viot-v5.pdf I'm afraid this could increase fragmentation as guests would need to implement or modify their support for all of DMAR, IVRS and IORT. If we end up doing VIOT, I suggest limiting it to IORT. (2) In addition, there are some concerns about having virtio depend on ACPI or DT. Some hypervisors (Firecracker, QEMU microvm, kvmtool x86 [1]) don't currently implement those methods. It was suggested to embed the topology description into the device. It can work, as demonstrated at the end of this RFC, with the following limitations: - The topology description must be read before any endpoint managed by the IOMMU is probed, and even before the virtio module is loaded. This RFC uses a PCI quirk to manually parse the virtio configuration. It assumes that all endpoints managed by the IOMMU are under this same PCI host. - I don't have a solution for the virtio-mmio transport at the moment, because I haven't had time to modify a host to test it. I think it could either use a notifier on the platform bus, or better, a new 'iommu' command-line argument to the virtio-mmio driver. So the current prototype doesn't work for firecracker and microvm, which rely on virtio-mmio. - For Arm, if the platform has an ITS, the hypervisor needs IORT or DT to describe it anyway. More generally, not using either ACPI or DT might prevent from supporting other features as well. I suspect the above users will have to implement a standard method sooner or later. - Even when reusing as much existing code as possible, guest support is still going to be around a few hundred lines since we can't rely on the normal virtio infrastructure to be loaded at that point. As you can see below, the diffstat for the incomplete topology implementation is already bigger than the exhaustive IORT support, even when jumping through the VIOT hoop. So it's a lightweight solution for very specific use-cases, and we should still support ACPI for the general case. Multi-platform guests such as Linux will then need to support three topology descriptions instead of two. In this RFC I present both solutions, but I'd rather not keep all of it. Please see the individual patches for details: (1) Patches 1, 3-10 add support for virtio-iommu to the Linux IORT driver and patches 2, 11 add the VIOT glue. (2) Patch 12 adds the built-in topology description to the virtio-iommu specification. Patch 13 is a partial implementation for the Linux virtio-iommu driver. It only supports PCI, not platform devices. You can find Linux and QEMU code on my virtio-iommu/devel branches at http://jpbrucker.net/git/linux and http://jpbrucker.net/git/qemu I split the diffstat since there are two independent features. The first one is for patches 1-11, and the second one for patch 13. Jean-Philippe Brucker (11): ACPI/IORT: Move IORT to the ACPI folder ACPI: Add VIOT definitions ACPI/IORT: Allow registration of external tables ACPI/IORT: Add node categories ACPI/IORT: Support VIOT virtio-mmio node ACPI/IORT: Support VIOT virtio-pci node ACPI/IORT: Defer probe until virtio-iommu-pci has registered a fwnode ACPI/IORT: Add callback to update a device's fwnode iommu/virtio: Create fwnode if necessary iommu/virtio: Update IORT fwnode ACPI: Add VIOT table MAINTAINERS | 9 + drivers/acpi/Kconfig | 7 + drivers/acpi/Makefile | 2 + drivers/acpi/arm64/Kconfig | 3 - drivers/acpi/arm64/Makefile | 1 - drivers/acpi/bus.c | 2 + drivers/acpi/{arm64 => }/iort.c | 317 ++++++++++++++++++++++++++------ drivers/acpi/tables.c | 2 +- drivers/acpi/viot.c | 44 +++++ drivers/iommu/Kconfig | 1 + drivers/iommu/virtio-iommu.c | 61 +++++- include/acpi/actbl2.h | 31 ++++ include/linux/acpi_iort.h | 14 ++ include/linux/acpi_viot.h | 20 ++ 14 files changed, 448 insertions(+), 66 deletions(-) rename drivers/acpi/{arm64 => }/iort.c (86%) create mode 100644 drivers/acpi/viot.c create mode 100644 include/linux/acpi_viot.h Jean-Philippe Brucker (1): iommu/virtio: Add topology description to virtio-iommu config space drivers/base/platform.c | 3 + drivers/iommu/Kconfig | 9 + drivers/iommu/Makefile | 1 + drivers/iommu/virtio-iommu-topology.c | 410 ++++++++++++++++++++++++++ drivers/iommu/virtio-iommu.c | 3 + drivers/pci/pci-driver.c | 3 + include/linux/virtio_iommu.h | 18 ++ include/uapi/linux/virtio_iommu.h | 26 ++ 8 files changed, 473 insertions(+) create mode 100644 drivers/iommu/virtio-iommu-topology.c create mode 100644 include/linux/virtio_iommu.h [1] firecracker: https://github.com/firecracker-microvm/firecracker microvm: https://github.com/qemu/qemu/blob/master/docs/microvm.rst kvmtool: https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/ -- 2.24.0