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=-5.3 required=3.0 tests=BAYES_00, 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 B0724C5517A for ; Wed, 11 Nov 2020 16:09:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5FA1D206A1 for ; Wed, 11 Nov 2020 16:09:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726492AbgKKQJe (ORCPT ); Wed, 11 Nov 2020 11:09:34 -0500 Received: from mga18.intel.com ([134.134.136.126]:60998 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726039AbgKKQJc (ORCPT ); Wed, 11 Nov 2020 11:09:32 -0500 IronPort-SDR: CHnRG5mK8ua0OawsEd3hb4z+8VmUmTvV8Z5SyM90QXNibLLtzJxQUJMSMUe7/b/jUV0fsG4mLT Cdpz+ehEo4rg== X-IronPort-AV: E=McAfee;i="6000,8403,9802"; a="157948171" X-IronPort-AV: E=Sophos;i="5.77,469,1596524400"; d="scan'208";a="157948171" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Nov 2020 08:09:25 -0800 IronPort-SDR: EW2Gn5lekgEEaWvuCQ3EyLMVRtnPSYUNZxkgUPKKhjF88REFxVtROUsKgX+GB191bScIonsPAO a3PjIGKoDDDg== X-IronPort-AV: E=Sophos;i="5.77,469,1596524400"; d="scan'208";a="356697354" Received: from otc-nc-03.jf.intel.com (HELO otc-nc-03) ([10.54.39.36]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Nov 2020 08:09:24 -0800 Date: Wed, 11 Nov 2020 08:09:22 -0800 From: "Raj, Ashok" To: Christoph Hellwig Cc: David Woodhouse , Thomas Gleixner , Jason Gunthorpe , Dan Williams , "Tian, Kevin" , "Jiang, Dave" , Bjorn Helgaas , "vkoul@kernel.org" , "Dey, Megha" , "maz@kernel.org" , "bhelgaas@google.com" , "alex.williamson@redhat.com" , "Pan, Jacob jun" , "Liu, Yi L" , "Lu, Baolu" , "Kumar, Sanjay K" , "Luck, Tony" , "jing.lin@intel.com" , "kwankhede@nvidia.com" , "eric.auger@redhat.com" , "parav@mellanox.com" , "rafael@kernel.org" , "netanelg@mellanox.com" , "shahafs@mellanox.com" , "yan.y.zhao@linux.intel.com" , "pbonzini@redhat.com" , "Ortiz, Samuel" , "Hossain, Mona" , "dmaengine@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , "kvm@vger.kernel.org" , Ashok Raj Subject: Re: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection Message-ID: <20201111160922.GA83266@otc-nc-03> References: <20201104135415.GX2620339@nvidia.com> <20201106131415.GT2620339@nvidia.com> <20201106164850.GA85879@otc-nc-03> <20201106175131.GW2620339@nvidia.com> <20201107001207.GA2620339@nvidia.com> <87pn4nk7nn.fsf@nanos.tec.linutronix.de> <20201111154159.GA24059@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201111154159.GA24059@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, Nov 11, 2020 at 03:41:59PM +0000, Christoph Hellwig wrote: > On Sun, Nov 08, 2020 at 07:36:34PM +0000, David Woodhouse wrote: > > So it does look like we're going to need a hypercall interface to > > compose an MSI message on behalf of the guest, for IMS to use. In fact > > PCI devices assigned to a guest could use that too, and then we'd only > > need to trap-and-remap any attempt to write a Compatibility Format MSI > > to the device's MSI table, while letting Remappable Format messages get > > written directly. > > > > We'd also need a way for an OS running on bare metal to *know* that > > it's on bare metal and can just compose MSI messages for itself. Since > > we do expect bare metal to have an IOMMU, perhaps that is just a > > feature flag on the IOMMU? > > Have the platform firmware advertise if it needs native or virtualized > IMS handling. If it advertises neither don't support IMS? The platform hint can be easily accomplished via DMAR table flags. We could have an IMS_OPTOUT(similart to x2apic optout flag) flag, when 0 its native and IMS is supported. When vIOMMU is presented to guest, virtual DMAR table will have this flag set to 1. Indicates to GuestOS, native IMS isn't supported.