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 DF685C433EF for ; Fri, 24 Jun 2022 14:09:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232491AbiFXOJF (ORCPT ); Fri, 24 Jun 2022 10:09:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232531AbiFXOIx (ORCPT ); Fri, 24 Jun 2022 10:08:53 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A2364FC4D for ; Fri, 24 Jun 2022 07:08:52 -0700 (PDT) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LTzVV11Wqz67sTc; Fri, 24 Jun 2022 22:08:18 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml701-chm.china.huawei.com (10.206.15.50) 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:08:49 +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:08:48 +0100 Date: Fri, 24 Jun 2022 15:08:44 +0100 From: Jonathan Cameron 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: <20220624150844.000005ec@Huawei.com> In-Reply-To: References: <20220616141950.23374-1-Jonathan.Cameron@huawei.com> <20220616141950.23374-2-Jonathan.Cameron@huawei.com> <20220624133909.00005f6e@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 Precedence: bulk List-ID: X-Mailing-List: linux-cxl@vger.kernel.org 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. 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 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 0BA76C43334 for ; Fri, 24 Jun 2022 14:45:25 +0000 (UTC) Received: from localhost ([::1]:35144 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4kYl-0002X8-AG for qemu-devel@archiver.kernel.org; Fri, 24 Jun 2022 10:45:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44414) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4jzV-0003bS-Hh; Fri, 24 Jun 2022 10:08:57 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:2637) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4jzR-00014z-GU; Fri, 24 Jun 2022 10:08:56 -0400 Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LTzVV11Wqz67sTc; Fri, 24 Jun 2022 22:08:18 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml701-chm.china.huawei.com (10.206.15.50) 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:08:49 +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:08:48 +0100 Date: Fri, 24 Jun 2022 15:08:44 +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: <20220624150844.000005ec@Huawei.com> In-Reply-To: References: <20220616141950.23374-1-Jonathan.Cameron@huawei.com> <20220616141950.23374-2-Jonathan.Cameron@huawei.com> <20220624133909.00005f6e@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 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. 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