From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFFCCC3F2D1 for ; Wed, 4 Mar 2020 13:37:17 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B24FF20870 for ; Wed, 4 Mar 2020 13:37:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B24FF20870 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 6F9D884837; Wed, 4 Mar 2020 13:37:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxYhW6unvLwR; Wed, 4 Mar 2020 13:37:16 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by fraxinus.osuosl.org (Postfix) with ESMTP id CEC4F85EF3; Wed, 4 Mar 2020 13:37:16 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id BCCBDC1D8E; Wed, 4 Mar 2020 13:37:16 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 215BAC013E; Wed, 4 Mar 2020 13:37:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0A7F584837; Wed, 4 Mar 2020 13:37:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_s1KHe7iE9h; Wed, 4 Mar 2020 13:37:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by fraxinus.osuosl.org (Postfix) with ESMTPS id BE1E984799; Wed, 4 Mar 2020 13:37:13 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id 3690C3A4; Wed, 4 Mar 2020 14:37:11 +0100 (CET) Date: Wed, 4 Mar 2020 14:37:08 +0100 From: Joerg Roedel To: "Michael S. Tsirkin" Subject: Re: [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space Message-ID: <20200304133707.GB4177@8bytes.org> References: <20200228172537.377327-1-jean-philippe@linaro.org> <20200228172537.377327-2-jean-philippe@linaro.org> <20200302161611.GD7829@8bytes.org> <9004f814-2f7c-9024-3465-6f9661b97b7a@redhat.com> <20200303130155.GA13185@8bytes.org> <20200303084753-mutt-send-email-mst@kernel.org> <20200303155318.GA3954@8bytes.org> <20200303105523-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200303105523-mutt-send-email-mst@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Jean-Philippe Brucker , kevin.tian@intel.com, linux-pci@vger.kernel.org, jasowang@redhat.com, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, sebastien.boeuf@intel.com, jacob.jun.pan@intel.com, bhelgaas@google.com, robin.murphy@arm.com X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices, and that means describing hardware through ACPI. > This "hardware" is actually part of hypervisor so there's no > reason it can't be completely self-descriptive. It's specified > by the same entity as the "firmware". That is just an implementation detail. Yes, QEMU emulates the hardware and builds the ACPI tables. But it could also be implemented in a way where the ACPI tables are build by guest firmware. > I don't see why it would be much faster. The interface isn't that > different from command queues of VTD. VirtIO IOMMU doesn't need to build page-tables that the hypervisor then has to shadow, which makes things much faster. If you emulate one of the other IOMMUs (VT-d or AMD-Vi) the code has to shadow the full page-table at once when device passthrough is used. VirtIO-IOMMU doesn't need that, and that makes it much faster and efficient. > Making ACPI meet the goals of embedded projects such as kata containers > would be a gigantic task with huge stability implications. By > comparison this 400-line parser is well contained and does the job. I > didn't yet see compelling reasons not to merge this, but I'll be > interested to see some more specific concerns. An ACPI table parse wouldn't need more lines of code. For embedded systems there is still the DT way of describing things. Regards, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4640FC3F2D1 for ; Wed, 4 Mar 2020 13:37:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 21CA62166E for ; Wed, 4 Mar 2020 13:37:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729499AbgCDNhM (ORCPT ); Wed, 4 Mar 2020 08:37:12 -0500 Received: from 8bytes.org ([81.169.241.247]:49992 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729494AbgCDNhM (ORCPT ); Wed, 4 Mar 2020 08:37:12 -0500 Received: by theia.8bytes.org (Postfix, from userid 1000) id 3690C3A4; Wed, 4 Mar 2020 14:37:11 +0100 (CET) Date: Wed, 4 Mar 2020 14:37:08 +0100 From: Joerg Roedel To: "Michael S. Tsirkin" Cc: Auger Eric , Jean-Philippe Brucker , iommu@lists.linux-foundation.org, virtualization@lists.linux-foundation.org, linux-pci@vger.kernel.org, bhelgaas@google.com, jasowang@redhat.com, kevin.tian@intel.com, sebastien.boeuf@intel.com, jacob.jun.pan@intel.com, robin.murphy@arm.com Subject: Re: [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space Message-ID: <20200304133707.GB4177@8bytes.org> References: <20200228172537.377327-1-jean-philippe@linaro.org> <20200228172537.377327-2-jean-philippe@linaro.org> <20200302161611.GD7829@8bytes.org> <9004f814-2f7c-9024-3465-6f9661b97b7a@redhat.com> <20200303130155.GA13185@8bytes.org> <20200303084753-mutt-send-email-mst@kernel.org> <20200303155318.GA3954@8bytes.org> <20200303105523-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200303105523-mutt-send-email-mst@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices, and that means describing hardware through ACPI. > This "hardware" is actually part of hypervisor so there's no > reason it can't be completely self-descriptive. It's specified > by the same entity as the "firmware". That is just an implementation detail. Yes, QEMU emulates the hardware and builds the ACPI tables. But it could also be implemented in a way where the ACPI tables are build by guest firmware. > I don't see why it would be much faster. The interface isn't that > different from command queues of VTD. VirtIO IOMMU doesn't need to build page-tables that the hypervisor then has to shadow, which makes things much faster. If you emulate one of the other IOMMUs (VT-d or AMD-Vi) the code has to shadow the full page-table at once when device passthrough is used. VirtIO-IOMMU doesn't need that, and that makes it much faster and efficient. > Making ACPI meet the goals of embedded projects such as kata containers > would be a gigantic task with huge stability implications. By > comparison this 400-line parser is well contained and does the job. I > didn't yet see compelling reasons not to merge this, but I'll be > interested to see some more specific concerns. An ACPI table parse wouldn't need more lines of code. For embedded systems there is still the DT way of describing things. Regards, Joerg