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=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 C0F26C433B4 for ; Thu, 15 Apr 2021 13:31:36 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 826D46105A for ; Thu, 15 Apr 2021 13:31:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 826D46105A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.111153.212528 (Exim 4.92) (envelope-from ) id 1lX25f-00019v-NO; Thu, 15 Apr 2021 13:31:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 111153.212528; Thu, 15 Apr 2021 13:31:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lX25f-00019o-IP; Thu, 15 Apr 2021 13:31:27 +0000 Received: by outflank-mailman (input) for mailman id 111153; Thu, 15 Apr 2021 13:31:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lX25f-00019j-29 for xen-devel@lists.xenproject.org; Thu, 15 Apr 2021 13:31:27 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lX25Y-0000SY-3p; Thu, 15 Apr 2021 13:31:20 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lX25X-0001sx-ID; Thu, 15 Apr 2021 13:31:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=DqsX+LfO2Qc+1KbTD1msTfiRaFiBnsHRKFpXG1msmPU=; b=RQX6RiWZhuM/944bC8Vjs9znQy 0AcJ5vvOGm7F3t1vm1d6weF2yy5RbUHqcK93nKCRbc8qcCiAgzrraWgmDlMyGniQ61JlIRrpA1UIM NJ4kbVpYClCwzEmVnS1jcU37E1kp2spdKvL1c2FtWQj/zh4WQFA6wbSzqskMBp2YfrVs=; Subject: Re: [PATCH v2] xen/pci: Refactor PCI MSI interrupts related code To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: Rahul Singh , xen-devel@lists.xenproject.org, bertrand.marquis@arm.com, Jan Beulich , Andrew Cooper , Wei Liu , George Dunlap , Ian Jackson , Stefano Stabellini , Paul Durrant , Volodymyr Babchuk , Daniel De Graaf References: <258c91c7-e733-3c40-5e4e-7b107e4d20c3@xen.org> From: Julien Grall Message-ID: <788665ad-9815-e3e9-2d5a-851b35c566d0@xen.org> Date: Thu, 15 Apr 2021 14:31:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Hi Roger, On 15/04/2021 14:26, Roger Pau Monné wrote: > On Wed, Apr 14, 2021 at 09:49:37AM +0100, Julien Grall wrote: >> Hi Roger, >> >> On 14/04/2021 09:05, Roger Pau Monné wrote: >>> On Tue, Apr 13, 2021 at 06:12:10PM +0100, Julien Grall wrote: >>>> Hi Roger, >>>> >>>> On 12/04/2021 11:49, Roger Pau Monné wrote: >>>>> On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote: >>>>>> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c >>>>>> index 705137f8be..1b473502a1 100644 >>>>>> --- a/xen/drivers/passthrough/pci.c >>>>>> +++ b/xen/drivers/passthrough/pci.c >>>>>> @@ -1303,12 +1279,15 @@ static int __init setup_dump_pcidevs(void) >>>>>> } >>>>>> __initcall(setup_dump_pcidevs); >>>>>> + >>>>>> +#ifdef CONFIG_PCI_MSI_INTERCEPT >>>>>> int iommu_update_ire_from_msi( >>>>>> struct msi_desc *msi_desc, struct msi_msg *msg) >>>>>> { >>>>>> return iommu_intremap >>>>>> ? iommu_call(&iommu_ops, update_ire_from_msi, msi_desc, msg) : 0; >>>>>> } >>>>>> +#endif >>>>> >>>>> This is not exactly related to MSI intercepts, the IOMMU interrupt >>>>> remapping table will also be used for interrupt entries for devices >>>>> being used by Xen directly, where no intercept is required. >>>> >>>> On Arm, this is not tie to the IOMMU. Instead, this handled is a separate >>>> MSI controller (such as the ITS). >>>> >>>>> >>>>> And then you also want to gate the hook from iommu_ops itself with >>>>> CONFIG_PCI_MSI_INTERCEPT, if we want to got this route. >>>> >>>> >>>> All the callers are in the x86 code. So how about moving the function in an >>>> x86 specific file? >>> >>> Yes, that seems fine. Just place it in asm-x86/iommu.h. I wonder why >>> update_ire_from_msi wasn't moved when the rest of the x86 specific >>> functions where moved there. >> >> I am guessing it is because the function was protected by CONFIG_HAS_PCI >> rather than CONFIG_X86. So it was deferred until another arch enables >> CONFIG_HAS_PCI (it is easier to know what code should be moved). >> >>> Was there an aim to use that in other >>> arches? >> >> In the future we may need to use MSIs in Xen (IIRC some SMMUs only support >> MSI interrupt). > > Then I think some of the bits that are moved from > xen/drivers/passthrough/pci.c (alloc_pci_msi, free_pci_msi and > dump_pci_msi) need to be protected by a Kconfig option different than > CONFIG_PCI_MSI_INTERCEPT, as those are not related to MSI interception, > but to MSI handling in general (ie: Xen devices using MSI need > those). Well... x86-specific devices yes. We don't know in what form MSI will be added on for other arch-specific devices. The same with the msi_list and msix fields of pci_dev, those > are not only used for MSI interception. > > Or at least might be worth mentioning that the functions will be > needed for Xen to be able to use MSI interrupts itself, even if not > for interception purposes. My preference would be to comment in the commit message (although, there is no promise they will ever get re-used). We can then modify the #ifdef once we introduce any use. Cheers, -- Julien Grall