Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1814160rwb; Thu, 17 Nov 2022 02:20:33 -0800 (PST) X-Google-Smtp-Source: AA0mqf55rGihaPMK33JcyKS4K7pteZaRCfsN3SmjbB0msDNofvk76X7yHmLKH4YPZbIwWhuEQY3u X-Received: by 2002:aa7:86c7:0:b0:562:45f0:df50 with SMTP id h7-20020aa786c7000000b0056245f0df50mr2418964pfo.16.1668680433660; Thu, 17 Nov 2022 02:20:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668680433; cv=none; d=google.com; s=arc-20160816; b=IdIidOkQ8CbKdgBIueem4V+lB76o+SIDGMHfUIbOkU41hwEoHNopS4fUrSlmLMS/F/ GqeqeHNypDlaPoYT4pCNFkj1CZOB5bn3+v0XGioTDhwILMVfHtPUElR513HK9m00kfm/ XLbGQgJpZZEhQDtG2q5MA2yDyGGLzBRqOOjwoFagf0i4inTeCdzmKt0oYiYEmqGKSvbr lekHgZwSAGj7JFJrG9UrcRtn9gfQvh5wjkPXEtCHMHv8r5YkNmwaPDP0fR4/QKAubwBq 0vajs48Ca2XFL63rqTAmmoM5IyMbdfteoj1gz/MYIE12xY1K6e0ws8DFEWWgUVmgg8mx ZYeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=gquu1ZTTEBDKIhI2pV8dgt1FSaeBDeaXtLNdg4+XaPk=; b=WpZiKNf1OxwHvU5ps+E1Zp8q+EX2P0OBnlPPSgcEjHs7kiPcH+j7frahy1ec3niThq fBI2TWrs4tlBDcMUZ+5qaMpXInMZ4GsTBZWVFu21CUyT8brOVL4K1Xlt+j8Aeyfgomyl WgmCLCWp+BNRCODw5lIfpddZR7BUkF3FqWAVd+vkL+B2O5Hq8aW14NYwBDlmftpj110r PGQRhvRuVrLqIJ4JnwkKk+fdqxAqpVk90uua78hrodp8nCqpalUh005U8atimQqpwR4I a3Nnp8eel5QCXPN3SvC7oh/OXB8lS2KqZ7ZMIYRBbEBgjgrxLLh5huhl/E44IVnbYp1Z Ve3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=wNcCk0qk; dkim=neutral (no key) header.i=@linutronix.de header.b=btkKxgoo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q9-20020a638c49000000b00476c8632d24si596545pgn.686.2022.11.17.02.20.21; Thu, 17 Nov 2022 02:20:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=wNcCk0qk; dkim=neutral (no key) header.i=@linutronix.de header.b=btkKxgoo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234515AbiKQJqi (ORCPT + 91 others); Thu, 17 Nov 2022 04:46:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233220AbiKQJqh (ORCPT ); Thu, 17 Nov 2022 04:46:37 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 488483204D; Thu, 17 Nov 2022 01:46:36 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1668678394; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gquu1ZTTEBDKIhI2pV8dgt1FSaeBDeaXtLNdg4+XaPk=; b=wNcCk0qkTgyuNsVHaiNO8d3XS6+hY6fnnDIcMzVj36njCY6on15RXkl31j0Kk7Bdjjr8Eb VEKpv5K8wsJDfHX5iVN/n/2Ncea2ha6qd88Te7u4zYrZwzCR1HmQN3zAc8zuuogdqtB7F2 rx6ZeLx2cI2hERpe/EQNVKBirR7HIFDyhrUKlblLX8Dg/uN40l9FPmJG8RmCDuAjfZH5o7 E6zK+bTgfVlEb7QNOF2g6n1rCdi8xWL/sdjgBC0gStORRw6gnSEqesZAUS2r7ys227bzVw XuyDy4qTFrMHDDrzaLtdMoMkGbeUQZUSkmkuphcE59dXRhSFJIuakhOOVFd+1g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1668678394; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gquu1ZTTEBDKIhI2pV8dgt1FSaeBDeaXtLNdg4+XaPk=; b=btkKxgoo4G39juKRAY25iro1A6DK9xxOm+3epNLxGy3fLzh3vnkeIqjlYNlKy18H53IJeY 0hUwo4ykI4F0u6Cw== To: Jason Gunthorpe Cc: LKML , x86@kernel.org, Joerg Roedel , Will Deacon , linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Marc Zyngier , Greg Kroah-Hartman , Dave Jiang , Alex Williamson , Kevin Tian , Dan Williams , Logan Gunthorpe , Ashok Raj , Jon Mason , Allen Hubbe , "Ahmed S. Darwish" , Reinette Chatre Subject: Re: [patch 27/33] genirq/msi: Provide constants for PCI/IMS support In-Reply-To: References: <20221111133158.196269823@linutronix.de> <20221111135206.800062166@linutronix.de> Date: Thu, 17 Nov 2022 10:46:34 +0100 Message-ID: <87o7t5ncat.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 16 2022 at 15:54, Jason Gunthorpe wrote: > On Fri, Nov 11, 2022 at 02:58:54PM +0100, Thomas Gleixner wrote: >> + /* Support for PCI/IMS */ >> + MSI_FLAG_PCI_IMS = (1 << 21), > > Maybe for legacy reasons it is too complicated, but it would be so > much clearer of the special case of "I only know how to support PCI > MSI and PCI MSI-X" was called out as a special flag, and the more > general case of "any write_msg is fine by me" was left behind. > > I feel like when the device domain is created in the first place the > parent domain(s) should be able to reject the creation if the > requested child domain is not one it supports. Eg the hypervisor > interactions checks if the child domain is PCI MSI or PCI MSI-X and > rejects otherwise, because that is the only thing the hypervisor knows > how to work with. > > If we did that perhaps we don't even need a flag or further checks? It's not that simple. The flags are part of the domain creation sanity checks and due to other constraints in our marvelous zoo of architectures, iommus, hypervisors and whatever being explicit about this is really required. Look at the GICv3-ITS voodoo which explicitly needs to differentiate between PCI and non-PCI MSI. I wish we could start from a clean slate, but that train has left the station long ago. Thanks, tglx