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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.