From: Sean Christopherson <seanjc@google.com>
To: Hisam Mehboob <hisamshar@gmail.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, shuah@kernel.org,
linux-kselftest@vger.kernel.org,
David Matlack <dmatlack@google.com>
Subject: Re: [PATCH v2] KVM: selftests: Replace ulong with unsigned long
Date: Tue, 18 Aug 2026 12:28:34 -0700 [thread overview]
Message-ID: <aoSyYtxBpEaoBwGY@google.com> (raw)
In-Reply-To: <c2f7e904-2646-4b01-864d-d185221c7f56@gmail.com>
+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/am0KqJOD-FiC9BXs@google.com
>
> 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"?
> 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?
> The rseq __GNUC_PREREQ failure is already covered by my patch in
> linux-next. With the above sorted, the musl build passes.
next prev parent reply other threads:[~2026-08-18 19:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 17:08 [PATCH v2] KVM: selftests: Replace ulong with unsigned long Hisam Mehboob
2026-08-17 22:04 ` Hisam Mehboob
2026-08-17 22:24 ` Sean Christopherson
2026-08-17 22:42 ` Hisam Mehboob
2026-08-18 16:27 ` Sean Christopherson
2026-08-18 18:19 ` Hisam Mehboob
2026-08-18 19:28 ` Sean Christopherson [this message]
2026-08-18 21:03 ` Hisam Mehboob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoSyYtxBpEaoBwGY@google.com \
--to=seanjc@google.com \
--cc=dmatlack@google.com \
--cc=hisamshar@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox