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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDE88C433FE for ; Thu, 17 Nov 2022 09:46:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229931AbiKQJqi (ORCPT ); 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 Precedence: bulk List-ID: X-Mailing-List: linux-pci@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