From: Sean Christopherson <seanjc@google.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Mark Brown <broonie@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, anup@brainfault.org
Subject: Re: [PATCH] KVM: selftests: Enable USERFAULTFD
Date: Mon, 6 Feb 2023 18:15:16 +0000 [thread overview]
Message-ID: <Y+FDtDWnG2k0wqlv@google.com> (raw)
In-Reply-To: <Y+E0MuGJ+hE3zslT@google.com>
On Mon, Feb 06, 2023, Oliver Upton wrote:
> +cc x86, riscv as they're also affected.
>
> On Thu, Feb 02, 2023 at 09:01:36PM +0000, Mark Brown wrote:
> > The page_fault_test KVM selftest requires userfaultfd but the config
> > fragment for the KVM selftests does not enable it, meaning that those tests
> > are skipped in CI systems that rely on appropriate settings in the config
> > fragments except on S/390 which happens to have it in defconfig. Enable
> > the option in the config fragment so that the tests get run.
What do CI systems do for HugeTLB and THP? Those are the other config options I
can think of where there are very interesting interactions from a KVM perspective,
but where KVM doesn't have a strict dependency on the feature.
E.g. x86_64_defconfig selects CONFIG_HUGETLBFS=y, but I don't see anything for THP,
and AFAICT TRANSPARENT_HUGEPAGE is default=n.
> Thanks for catching this.
>
> I believe we also need UFFD for demand_paging_test, which is used by all
> the KVM selftests arches. I plan on picking this up, but if anyone has
> objections please shout :)
All yours.
Reviewed-by: Sean Christopherson <seanjc@google.com>
next prev parent reply other threads:[~2023-02-06 18:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 21:01 [PATCH] KVM: selftests: Enable USERFAULTFD Mark Brown
2023-02-06 17:09 ` Oliver Upton
2023-02-06 18:15 ` Sean Christopherson [this message]
2023-02-06 19:49 ` Oliver Upton
2023-02-06 21:10 ` Mark Brown
2023-02-08 17:30 ` Oliver Upton
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=Y+FDtDWnG2k0wqlv@google.com \
--to=seanjc@google.com \
--cc=anup@brainfault.org \
--cc=broonie@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--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.