Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp5561547rwb; Wed, 7 Sep 2022 04:57:11 -0700 (PDT) X-Google-Smtp-Source: AA6agR4sm5+gf6yrR3wodug1ku8RCNoFNiHANJpE83+F72szAn8Yni6ft+gpJ1sX3k3nXO6NRuCp X-Received: by 2002:a17:90b:378b:b0:200:934a:5a35 with SMTP id mz11-20020a17090b378b00b00200934a5a35mr10277181pjb.91.1662551831090; Wed, 07 Sep 2022 04:57:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662551831; cv=none; d=google.com; s=arc-20160816; b=YgYfpckllJ6+6GTB8Yqq5DkqyYVgI7cj6cQh94KTzym+xpVIDO94TTWXKrQ3kIsbqb 7sK2scB8zg2ZH19yxQytp7VNeCK7XMgDGJVESNMRV17Uo/MSzUhGKUI62v8tp2avwNKT 6HL2FHpGYzcBi2dhs6YdWaSIYVZJD3z/mU6CVZuqJKLY1OhYlShJOA1V7Q+f72s88fHj Z10W/H5qWVBBCMkeo/TLayFveZnjcnkT979LUuheYEDEvI9Be4JAzkCJqGuTUN6Zn0nk fcMfAYlt2/W40hoB3vYJ36egrWU3ru17S93k4G/kMQ5tOCxrPKGdhSU59hUGTaXbbcnn Jm2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=VLUp+0Y9j1fRZ7OvrKpPQ47qazPmv3wSadDkbnrxDZM=; b=TjTQsAXynnqhEarVoa99mda1+7dfHwdDht8AgX7uJjViDKJCzB2xqacUpa/eEnF36O tNr36BL1YwsE49Fc2ZigM+PLXES6tH9eN9X1pkt5MK54pNDctOqxxCc/1Idvr+LkBlpW oYNyHOuxCvRQocKJPZio3CDKj7Sr9vZX0cen88/4crO6bHe9AYez57wYblnJkE7/npgV Z/vGoZdhNmHGLwApR60ajaYJ5pUMBi5Dl40qZhvuwvoooZ21muoY6Cfd0JWMEuLVE5N4 lpCSWKQaXy1XojO4XULIf89x6HXy3hGIjsSh5zIGj3NIGnVFWR+dKZ4FGZHf2QWLpM5G mz7g== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 200-20020a6304d1000000b0042bc924ed3bsi19020110pge.165.2022.09.07.04.57.00; Wed, 07 Sep 2022 04:57:11 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230109AbiIGLdg (ORCPT + 99 others); Wed, 7 Sep 2022 07:33:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230003AbiIGLd1 (ORCPT ); Wed, 7 Sep 2022 07:33:27 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AF3DBB69F0; Wed, 7 Sep 2022 04:33:25 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A8A4E1042; Wed, 7 Sep 2022 04:33:31 -0700 (PDT) Received: from [10.57.15.197] (unknown [10.57.15.197]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 63EA73F7B4; Wed, 7 Sep 2022 04:33:20 -0700 (PDT) Message-ID: <4ca6383e-bd21-59bf-cc4e-cf3313164957@arm.com> Date: Wed, 7 Sep 2022 12:33:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [RFC PATCH v3 4/7] bus/cdx: add cdx-MSI domain with gic-its domain as parent Content-Language: en-GB To: Marc Zyngier , Jason Gunthorpe Cc: Nipun Gupta , robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, gregkh@linuxfoundation.org, rafael@kernel.org, eric.auger@redhat.com, alex.williamson@redhat.com, cohuck@redhat.com, puneet.gupta@amd.com, song.bao.hua@hisilicon.com, mchehab+huawei@kernel.org, f.fainelli@gmail.com, jeffrey.l.hugo@gmail.com, saravanak@google.com, Michael.Srba@seznam.cz, mani@kernel.org, yishaih@nvidia.com, will@kernel.org, joro@8bytes.org, masahiroy@kernel.org, ndesaulniers@google.com, linux-arm-kernel@lists.infradead.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, kvm@vger.kernel.org, okaya@kernel.org, harpreet.anand@amd.com, nikhil.agarwal@amd.com, michal.simek@amd.com, aleksandar.radovanovic@amd.com, git@amd.com References: <20220803122655.100254-1-nipun.gupta@amd.com> <20220906134801.4079497-1-nipun.gupta@amd.com> <20220906134801.4079497-5-nipun.gupta@amd.com> <87leqvv3g7.wl-maz@kernel.org> From: Robin Murphy In-Reply-To: <87leqvv3g7.wl-maz@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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 2022-09-07 12:17, Marc Zyngier wrote: > On Tue, 06 Sep 2022 18:19:06 +0100, > Jason Gunthorpe wrote: >> >> On Tue, Sep 06, 2022 at 07:17:58PM +0530, Nipun Gupta wrote: >> >>> +static void cdx_msi_write_msg(struct irq_data *irq_data, >>> + struct msi_msg *msg) >>> +{ >>> + /* >>> + * Do nothing as CDX devices have these pre-populated >>> + * in the hardware itself. >>> + */ >>> +} >> >> Huh? >> >> There is no way it can be pre-populated, the addr/data pair, >> especially on ARM, is completely under SW control. > > There is nothing in the GIC spec that says that. > >> There is some commonly used IOVA base in Linux for the ITS page, but >> no HW should hardwire that. > > That's not strictly true. It really depends on how this block is > integrated, and there is a number of existing blocks that know *in HW* > how to signal an LPI. > > See, as the canonical example, how the mbigen driver doesn't need to > know about the address of GITS_TRANSLATER. > > Yes, this messes with translation (the access is downstream of the > SMMU) if you relied on it to have some isolation, and it has a "black > hole" effect as nobody can have an IOVA that overlaps with the > physical address of the GITS_TRANSLATER register. > > But is it illegal as per the architecture? No. It's just stupid. If that were the case, then we'd also need a platform quirk so the SMMU driver knows about it. Yuck. But even then, are you suggesting there is some way to convince the ITS driver to allocate a specific predetermined EventID when a driver requests an MSI? Asking for a friend... Cheers, Robin.