On Fri, 24 Jun 2022 15:08:44 +0100 Jonathan Cameron <jonathan.came...@huawei.com> wrote:
> On Fri, 24 Jun 2022 13:56:32 +0100 > Peter Maydell <peter.mayd...@linaro.org> wrote: > > > On Fri, 24 Jun 2022 at 13:39, Jonathan Cameron > > <jonathan.came...@huawei.com> wrote: > > > > > > On Fri, 24 Jun 2022 11:48:47 +0100 > > > Peter Maydell <peter.mayd...@linaro.org> 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 > >