On Wed, Aug 11, 2021 at 1:50 PM Ben Widawsky <[email protected]> wrote: > > On Tue, 10 Aug 2021 15:40, Dan Williams <[email protected]> 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.
