On 8/19/26 00:28, Sean Christopherson wrote:
+David for the VFIO thing
On Tue, Aug 18, 2026, Hisam Mehboob wrote:
On 8/18/26 21:27, Sean Christopherson wrote:
Oh, so on top of "https://github.com/kvm-x86/linux.git next", this *is* the last
blocker? If so, then I'll grab this for 7.3.
Not quite -- I tested kvm-x86/next + this patch with musl-gcc, and the
build still fails. On top of the steal_time fix already in your tree,
two more musl blockers remain, both from code that is only in
kvm-x86/next so far:
1. hardware_disable_test.c, from 496779b54943 ("Pre-set threads affinity
in hardware disable test when possible"):
hardware_disable_test.c:75: error: implicit declaration of function
'pthread_attr_setaffinity_np'
The call sits under #ifdef _GNU_SOURCE, but lib.mk defines _GNU_SOURCE
unconditionally, so the path is always taken and musl (which lacks the
function) breaks.
Heh, Sashiko flagged that as problematic, and I was trying to figure out which
macro to key off of[*], but was (obviously) unsuccessful. I don't suppose you
know the canonical way for checking for support of glibc-only functionality of
this nature?
[*] https://lore.kernel.org/all/[email protected]
__GLIBC__ is the pragmatic in-tree answer.
_GNU_SOURCE is a request macro (input to the libc headers), not an
availability indicator -- lib.mk defines it unconditionally, so it
cannot detect anything. __USE_GNU works but is glibc-internal.
__GLIBC__ is defined by glibc's <features.h>, which any libc header
pulls in, and is the established idiom in selftests already:
kvm/lib/assert.c uses "#ifdef __GLIBC__" for execinfo.h, as do
bpf/test_progs.c and nolibc. musl deliberately provides no __MUSL__ --
its FAQ's stance is "test for properties, don't assume them", which
strictly implies a compile test (autoconf-style); with no configure
step in selftests, __GLIBC__ is the established in-tree idiom. For
hardware_disable_test.c that is s/_GNU_SOURCE/__GLIBC__/ in the three
spots; build-tested with musl-gcc, passes.
2. The libvfio wiring from a262fc49e0aa ("Build and link
selftests/vfio/lib into KVM selftests"):
vfio_pci_device.c:25: fatal error: uuid/uuid.h: No such file or
directory
sysfs.c:31: error: implicit declaration of function 'basename'
The former adds a hard libuuid dependency (its headers aren't visible
to musl-gcc here);
Can you elaborate on what you mean by "its headers aren't visible to musl-gcc"?
musl-gcc searches only its own include directories
(here: /usr/include/x86_64-linux-musl and gcc's internal dir) and
deliberately not /usr/include, to avoid mixing glibc-oriented headers
with musl. uuid/uuid.h comes from libuuid (util-linux) and is installed
at /usr/include/uuid/uuid.h for the glibc toolchain, so glibc builds
find it and musl builds cannot. I see 2f0c30d0d1 already limits the
libvfio link to x86; the remaining gap on x86 is that libuuid is now a
hard dependency of the KVM selftests build (libvfio.mk adds -luuid),
and for musl-x86 the header is not visible at all without a
musl-targeted libuuid install. A uuid.h compile check to skip the vfio
pieces would keep it optional; otherwise the new dependency is probably
worth documenting.
the latter because musl declares basename only in
<libgen.h>, while glibc exposes it via <string.h> under _GNU_SOURCE.
IIUC, sysfs.c just needs to explicitly include libgen.h?
Yes, adding <libgen.h> suffices. One nuance: there are two
flavors -- glibc under _GNU_SOURCE provides the GNU variant via
<string.h> (char *basename(const char *), non-modifying), while
<libgen.h> provides the POSIX variant (char *basename(char *), may
modify) and takes precedence on glibc as well. Safe at this call site:
rl_path is a writable buffer filled by readlink() (no trailing
slashes), used once by sscanf(). Verified with compile tests on both
libcs, and with <libgen.h> added, uuid/uuid.h is the only remaining
musl failure in the whole build.
The rseq __GNUC_PREREQ failure is already covered by my patch in
linux-next. With the above sorted, the musl build passes.
