On Mon, 2021-08-09 at 10:24 -0700, Dan Williams wrote:

On Mon, Aug 9, 2021 at 2:25 AM Johannes Berg [off-list ref] wrote:

quoted

From: Johannes Berg <redacted>

Now that UML has PCI support, this driver must depend also on
!UML since it pokes at X86_64 architecture internals that don't
exist on ARCH=um.

Do you really need to disable compilation of the whole driver just
because an arch level helper does not exist on UML builds? Isn't there
already a check for enqcmds on x86_64 to make sure the CPU is
sufficiently feature enabled?

Hmm?

The problem here is that cpuid_eax() and cpuid_ebx() don't even exist on
UML, and that's not really surprising - ARCH=um is after all compiled to
run as a userspace process, not to run on bare metal. I guess
technically we could provide (fake or even sort of real) implementations
of these, but there's very little point?

I don't see why you would ever possibly want to have this driver
compiled on ARCH=um, even if it's compiled for x86-64 "subarch", since
there will be no such device to run against?

johannes