Re: [PATCH 20/23] tools/testing/cxl: Introduce a mocked-up CXL port hierarchy

From: Dan Williams <dan.j.williams@intel.com>
To: Ben Widawsky <ben.widawsky@intel.com>
Cc: linux-cxl@vger.kernel.org, Linux NVDIMM <nvdimm@lists.linux.dev>,
	 Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Vishal L Verma <vishal.l.verma@intel.com>,
	 Alison <alison.schofield@intel.com>, Ira <ira.weiny@intel.com>
Subject: Re: [PATCH 20/23] tools/testing/cxl: Introduce a mocked-up CXL port hierarchy
Date: Wed, 11 Aug 2021 14:03:34 -0700	[thread overview]
Message-ID: <CAPcyv4jo6s9qz260K6oSpsZbKCdDvqcYxkxk=4PHLVVjzBSm2w@mail.gmail.com> (raw)
In-Reply-To: <xp0k4.l2r85dw1p7do@intel.com>

On Wed, Aug 11, 2021 at 1:50 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> On Tue, 10 Aug 2021 15:40, Dan Williams <dan.j.williams@intel.com> wrote:
>
> [snip]
>
> >
> >The rationale is to be able to run cxl_test on a system that might
> >also have real CXL. For example I run this alongside the current QEMU
> >CXL model, and that results in the cxl_acpi driver attaching to 2
> >devices:
> >
> ># tree /sys/bus/platform/drivers/cxl_acpi
> >/sys/bus/platform/drivers/cxl_acpi
> >├── ACPI0017:00 -> ../../../../devices/platform/ACPI0017:00
> >├── bind
> >├── cxl_acpi.0 -> ../../../../devices/platform/cxl_acpi.0
> >├── module -> ../../../../module/cxl_acpi
> >├── uevent
> >└── unbind
> >
> >When the device is ACPI0017 this code is walking the ACPI bus looking
> >for  ACPI0016 devices. A real ACPI0016 will fall through
> >is_mock_port() to the original to_cxl_host_bridge() logic that just
> >reads the ACPI device HID. In the mock case the cxl_acpi driver has
> >instead been tricked into walk the platform bus which has real
> >platform devices, and the fake cxl_test ones:
> >
> >/sys/bus/platform/devices/
> >├── ACPI0012:00 -> ../../../devices/platform/ACPI0012:00
> >├── ACPI0017:00 -> ../../../devices/platform/ACPI0017:00
> >├── alarmtimer.0.auto -> ../../../devices/pnp0/00:04/rtc/rtc0/alarmtimer.0.auto
> >├── cxl_acpi.0 -> ../../../devices/platform/cxl_acpi.0
> >├── cxl_host_bridge.0 -> ../../../devices/platform/cxl_host_bridge.0
> >├── cxl_host_bridge.1 -> ../../../devices/platform/cxl_host_bridge.1
> >├── cxl_host_bridge.2 -> ../../../devices/platform/cxl_host_bridge.2
> >├── cxl_host_bridge.3 -> ../../../devices/platform/cxl_host_bridge.3
> >├── e820_pmem -> ../../../devices/platform/e820_pmem
> >├── efi-framebuffer.0 -> ../../../devices/platform/efi-framebuffer.0
> >├── efivars.0 -> ../../../devices/platform/efivars.0
> >├── Fixed MDIO bus.0 -> ../../../devices/platform/Fixed MDIO bus.0
> >├── i8042 -> ../../../devices/platform/i8042
> >├── iTCO_wdt.1.auto -> ../../../devices/pci0000:00/0000:00:1f.0/iTCO_wdt.1.auto
> >├── kgdboc -> ../../../devices/platform/kgdboc
> >├── pcspkr -> ../../../devices/platform/pcspkr
> >├── PNP0103:00 -> ../../../devices/platform/PNP0103:00
> >├── QEMU0002:00 -> ../../../devices/pci0000:00/QEMU0002:00
> >├── rtc-efi.0 -> ../../../devices/platform/rtc-efi.0
> >└── serial8250 -> ../../../devices/platform/serial8250
> >
> >...where is_mock_port() filters out those real platform devices. Note
> >that ACPI devices are atypical in that they get registered on the ACPI
> >bus and some get a companion device with the same name registered on
> >the platform bus.
>
> More relevant to endpoints, but here too... Will we be able to have an
> interleave region comprised of a QEMU emulated device and a mock device? I think
> folks that are using QEMU for the hardware development purposes would really
> like that functionality.

I guess never say "never", but my intent was that the 2 bus-types were
distinct and the streams never crossed.