On 21/01/2025 17.34, Jonathan Cameron wrote: > On Thu, 12 Dec 2024 18:10:10 +0000 > Zhi Wang <z...@nvidia.com> wrote: > >> On 12/12/2024 18.49, Alejandro Lucero Palau wrote: >>> >>> On 12/12/24 13:04, Zhi Wang wrote: >>>> Hi folks: >>>> >>>> Per the discussion with Ira/Jonathan in the LPC 2024 and in the CXL >>>> discord channel, we are trying to introduce a CXL type-2 device emulation >>>> in QEMU, as there are work currently on supporting CXL type-2 device [1] >>>> in Linux kernel and CXL type-2 device virtualization [2]. >>>> >>>> It provides a bare minimum base for folks who would like to: >>>> >>>> - Contribute and test the CXL type-2 device support in the linux kernel >>>> and CXL type-2 virtualization without having an actual HW. >>>> - Introduce more emulated features to prototype the kernel CXL type-2 >>>> device features and CXL type-2 virtualization. >>>> >>>> To test this patchset, please refer to steps in [3]. Use this patcheset >>>> with the latest QEMU repo to be the QEMU host. It achieves the same >>>> output >>>> as in the demo video [4]: The VFIO CXL core and VFIO CXL sample variant >>>> driver can be attached to the emulated device in the L1 guest and >>>> assigned >>>> to the L2 guest. The sample driver in the L2 guest can attach to the >>>> pass-thrued device and create the CXL region. >>>> >>>> Tested on the CXL type-2 virtualization RFC patches [3] with an extra >>>> fix [5]. >>>> >>>> [1] https://nam11.safelinks.protection.outlook.com/? >>>> url=https%3A%2F%2Flore.kernel.org%2Flinux- >>>> cxl%2F20241209185429.54054-1-alejandro.lucero- >>>> palau%40amd.com%2FT%2F%23t&data=05%7C02%7Czhiw%40nvidia.com%7C3a61139bf3554f4f38f408dd1accf1b9%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638696189761390919%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6WziKnwMlZJQ4yxT2jLn7W1So0OfqYss78fOosuLiwA%3D&reserved=0 >>>> [2] https://nam11.safelinks.protection.outlook.com/? >>>> url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3De5OW1pR84Zs&data=05%7C02%7Czhiw%40nvidia.com%7C3a61139bf3554f4f38f408dd1accf1b9%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638696189761413039%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hTF%2F1I%2B4fYPQeCz7NhM0uvWd%2FrWfIzaKdcteD5%2BrcZ0%3D&reserved=0 >>>> [3] https://nam11.safelinks.protection.outlook.com/? >>>> url=https%3A%2F%2Flore.kernel.org%2Fkvm%2F20240920223446.1908673-3- >>>> zhiw%40nvidia.com%2FT%2F&data=05%7C02%7Czhiw%40nvidia.com%7C3a61139bf3554f4f38f408dd1accf1b9%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638696189761425646%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Wq3mr0mXZCbG3cXRKlibq%2BksTuwL8RGqiUS9jBFDfDY%3D&reserved=0 >>>> [4] https://nam11.safelinks.protection.outlook.com/? >>>> url=https%3A%2F%2Fyoutu.be%2Fzlk_ecX9bxs%3Fsi%3Dpf9CttcGT5KwUgiH&data=05%7C02%7Czhiw%40nvidia.com%7C3a61139bf3554f4f38f408dd1accf1b9%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638696189761437780%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SReTnBUC1bIhBwC%2BvASCXX%2F0ltIYcfWAkHXMmi%2FTRRg%3D&reserved=0 >>>> [5] https://nam11.safelinks.protection.outlook.com/? >>>> url=https%3A%2F%2Flore.kernel.org%2Flinux- >>>> cxl%2F20241212123959.68514-1- >>>> zhiw%40nvidia.com%2FT%2F%23u&data=05%7C02%7Czhiw%40nvidia.com%7C3a61139bf3554f4f38f408dd1accf1b9%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638696189761449589%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pmZ8JNctUlcLFwQLivNMkHj7fMt2PR24e%2BuHY%2Bk7bNA%3D&reserved=0 >>>> >>>> Zhi Wang (3): >>>> hw/cxl: factor out cxl_host_addr_to_dpa() >>>> hw/cxl: introduce cxl_component_update_dvsec() >>>> hw/cxl: introduce CXL type-2 device emulation >>>> >>>> MAINTAINERS | 1 + >>>> docs/system/devices/cxl.rst | 11 ++ >>>> hw/cxl/cxl-component-utils.c | 103 ++++++++++- >>>> hw/cxl/cxl-host.c | 19 +- >>>> hw/mem/Kconfig | 5 + >>>> hw/mem/cxl_accel.c | 319 +++++++++++++++++++++++++++++++++ >>>> hw/mem/cxl_type3.c | 61 +------ >>>> hw/mem/meson.build | 1 + >>>> include/hw/cxl/cxl_component.h | 7 + >>>> include/hw/cxl/cxl_device.h | 25 +++ >>>> include/hw/pci/pci_ids.h | 1 + >>>> 11 files changed, 484 insertions(+), 69 deletions(-) >>>> create mode 100644 hw/mem/cxl_accel.c >>>> >>> >>> Hi Zhi, >>> >>> >>> Thank you for this patchset. >>> >>> >>> I have a similar work done for helping in the Type2 support work, but >>> it is all quick-and-dirty changes. >>> >>> >>> My main concern here is with the optional features for Type2: how to >>> create an easy way for configuring Type2 devices using some qemu cxl >>> param. I'm afraid I did not work on that so no suggestions at all! >>> >> >> Hi Alejandro: >> >> No worries. The work is to provide a minimum base for CXL folks and CXL >> type-2 folks to start with, e.g. introducing more emulated features. As >> the type-3 emulation has been quite complicated and I was thinking maybe >> having a clean start would help. For re-factoring, I was mostly thinking >> of a step by step style: E.g. when both emulation of devices are >> reaching a point to have the common routines, then we re-factor them or >> draw a glue layer. >> >> Also, the patchset is good enough for people to test our works. >> >> If folks are OK on this minimum emulation, I think the next thing would >> be meaningful for us is aligning the plan for what features that we want >> to plug into this, so that we can share the efforts. >> >> The items on my list are: >> >> - Locked HDM decoder >> - CDAT and DOE >> >> I remembered you were talking about the configuration params, I think it >> can be very helpful on prototyping different features in the kernel as >> well. Feel free to reach out for discussions. >> > Rather than try to support every combination under the sun, I'd suggest > a couple of representative choices. Anyone developing the kernel can > come and tweak if they need other combinations of features. > > Typical test cases, so everything on, everything off, a mix or > two of features on. > > Trying to make something really configurable via parameters will end > up with nonsense combinations and just revealing bugs in the qemu emulation > rather than what we actually want to test. > > If you want to go really general though feel free to pitch it and we'll > see how bad it is. >
Agree. I am learning towards the switches should be use-case/device-feature oriented and that would be more aligned with the purpose of test and the requirement in reality. If there are really some special case of adding a quirk or something, we can justify them case by case. Z. > Jonathan > >> Z. >> >>> >>> Thank you >>> >> >
