All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Sean Christopherson <seanjc@google.com>
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 19:49:18 +0000	[thread overview]
Message-ID: <Y+FZvpxO62F9d2Ui@linux.dev> (raw)
In-Reply-To: <Y+FDtDWnG2k0wqlv@google.com>

On Mon, Feb 06, 2023 at 06:15:16PM +0000, Sean Christopherson wrote:
> 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.

Looks like arm64 defconfig enables THP and hugetlb. Regardless, I think
it would be valuable if our Kconfig fragment expressed the options that
buy us additional code coverage.

--
Thanks,
Oliver

  reply	other threads:[~2023-02-06 19:49 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
2023-02-06 19:49     ` Oliver Upton [this message]
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+FZvpxO62F9d2Ui@linux.dev \
    --to=oliver.upton@linux.dev \
    --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=pbonzini@redhat.com \
    --cc=seanjc@google.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.