Re: [PATCH v2] KVM: selftests: Replace ulong with unsigned long

On Tue, Aug 18, 2026 at 2:03 PM Hisam Mehboob <[email protected]> wrote:
>
> 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.

libuuid is required to build libvfio, which VFIO and KVM selftests
both depend on.

How is this problem solved for other libraries, like -lpthread?

> >
> >>     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.

Feel free to send a patch, or I can if you prefer.


>
> >> The rseq __GNUC_PREREQ failure is already covered by my patch in
> >> linux-next. With the above sorted, the musl build passes.
>