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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 12215C43334 for ; Fri, 24 Jun 2022 14:59:24 +0000 (UTC) Received: from localhost ([::1]:34168 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4kmJ-0004sE-5i for qemu-devel@archiver.kernel.org; Fri, 24 Jun 2022 10:59:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4khr-0007vw-UZ; Fri, 24 Jun 2022 10:54:47 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:2638) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4kho-0000yi-VT; Fri, 24 Jun 2022 10:54:47 -0400 Received: from fraeml705-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LV0Tc3sHVz67qfF; Fri, 24 Jun 2022 22:52:36 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml705-chm.china.huawei.com (10.206.15.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Fri, 24 Jun 2022 16:54:41 +0200 Received: from localhost (10.81.207.131) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 24 Jun 2022 15:54:40 +0100 Date: Fri, 24 Jun 2022 15:54:36 +0100 To: Peter Maydell CC: , , , "Michael S . Tsirkin" , Ben Widawsky , Paolo Bonzini , , , Marcel Apfelbaum , Igor Mammedov , Markus Armbruster , "Mark Cave-Ayland" , Adam Manzanares , Tong Zhang , "Shameerali Kolothum Thodi" , Dan Williams Subject: Re: [PATCH v11 1/2] hw/arm/virt: Basic CXL enablement on pci_expander_bridge instances pxb-cxl Message-ID: <20220624155436.000047cb@Huawei.com> In-Reply-To: <20220624150844.000005ec@Huawei.com> References: <20220616141950.23374-1-Jonathan.Cameron@huawei.com> <20220616141950.23374-2-Jonathan.Cameron@huawei.com> <20220624133909.00005f6e@Huawei.com> <20220624150844.000005ec@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.81.207.131] X-ClientProxiedBy: lhreml735-chm.china.huawei.com (10.201.108.86) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Received-SPF: pass client-ip=185.176.79.56; envelope-from=jonathan.cameron@huawei.com; helo=frasgout.his.huawei.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Reply-to: Jonathan Cameron From: Jonathan Cameron via On Fri, 24 Jun 2022 15:08:44 +0100 Jonathan Cameron wrote: > On Fri, 24 Jun 2022 13:56:32 +0100 > Peter Maydell wrote: > > > On Fri, 24 Jun 2022 at 13:39, Jonathan Cameron > > wrote: > > > > > > On Fri, 24 Jun 2022 11:48:47 +0100 > > > Peter Maydell wrote: > > > > > > > > This seems to be missing code to advertise the new devices in the > > > > device tree. > > > > > > Intentionally. I am not aware of any current interest > > > in defining DT support CXL or supporting it in operating systems. > > > Easy enough to add if anyone does the leg work to figure out the > > > bindings, but that needs to come from someone who cares and > > > would need to be driven by OS support and a usecase. The ACPI > > > stuff here is defined as part of the main CXL spec because the > > > target class of machines simply doesn't generally use DT. > > > > I don't really want new devices in the virt board that aren't > > usable in the common use case of "just pass a kernel with -kernel"... > > > > -- PMM > > Ok. In that case, what do you suggest? > > Options I can think of: > > 1) I can come up with plausible DT bindings, but I'm not sure how > that will be received by the kernel community, It will add a bunch of > infrastructure to maintain that may be seen as useless at least in > the short to medium term. Hence is not in anyone's test matrices etc. Just occurred to me there is another barrier to an approach that adds DT bindings. I fairly sure hw/pci-bridge/pci_expander_bridge.c (PXB) only works on ACPI platforms and is the only host bridge supported for CXL emulation in QEMU. > > Dan, how open would you be to adding DT support? We'd have to ignore > some of the firmware query stuff like QTGs as there isn't an equivalent > in DT - or we'd have to go as far as defining actual devices with > mailboxes to query that info. > > 2) Add it to something like the SBSA machine, but that brings a large > burden in firmware etc and need to communicate everything via DT to > EDK2 that is needed to build the ACPI tables in a flexible fashion + > mass of EDK2 development. Whilst the SBSA model is great for ARM > specific stuff, requiring the large additional complexity in > actually using it to test arch independent software is probably > going to just mean it bit rots. > > 3) Fork virt (obviously sharing as much as possible), potentially I > guess that could be pretty light weight by declaring a new > TypeInfo that is very nearly identical to virt with just the few extra > calls inserted. > > Any other routes open to me to getting this support available? > > Jonathan > >