From: Ben Gardon <bgardon@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>, kvm <kvm@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>, Peter Xu <peterx@redhat.com>,
David Matlack <dmatlack@google.com>,
Jim Mattson <jmattson@google.com>,
David Dunn <daviddunn@google.com>,
Jing Zhang <jingzhangos@google.com>,
Junaid Shahid <junaids@google.com>
Subject: Re: [PATCH 00/13] KVM: x86: Add a cap to disable NX hugepages on a VM
Date: Thu, 10 Mar 2022 13:29:15 -0600 [thread overview]
Message-ID: <CANgfPd9xr5ev7fEiwBVUi89iHkuywq-Ba9zOeCMSTFmLkO243w@mail.gmail.com> (raw)
In-Reply-To: <Yio8QtuMd6COcnEw@google.com>
On Thu, Mar 10, 2022 at 11:58 AM Sean Christopherson <seanjc@google.com> wrote:
>
> On Thu, Mar 10, 2022, Ben Gardon wrote:
> > selftests: KVM: Wrap memslot IDs in a struct for readability
> > selftests: KVM: Add memslot parameter to VM vaddr allocation
> > selftests: KVM: Add memslot parameter to elf_load
>
> I really, really, don't want to go down this path of proliferating memslot crud
> throughout the virtual memory allocators. I would much rather we solve this by
> teaching the VM creation helpers to (optionally) use hugepages. The amount of
> churn required just so that one test can back code with hugepages is absurd, and
> there's bound to be tests in the future that want to force hugepages as well.
I agree that proliferating the memslots argument isn't strictly
required for this test, but doing so makes it much easier to make
assertions about hugepage counts and such because you don't have your
stacks and page tables backed with hugepages.
Those patches are a lot of churn, but at least to me, they make the
code much more readable. Currently there are many functions which just
pass along 0 for the memslot, and often have multiple other numerical
arguments, which makes it hard to understand what the function is
doing.
I don't think explicitly specifying memslots really adds that much
overhead to the tests, and I'd rather have control over that than
implicitly cramming everything into memslot 0.
If you have a better way to manage the memslots and create virtual
mappings for / load code into other memslots, I'm open to it, but we
should do something about it.
next prev parent reply other threads:[~2022-03-10 19:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 16:45 [PATCH 00/13] KVM: x86: Add a cap to disable NX hugepages on a VM Ben Gardon
2022-03-10 16:45 ` [PATCH 01/13] selftests: KVM: Dump VM stats in binary stats test Ben Gardon
2022-03-10 16:45 ` [PATCH 02/13] selftests: KVM: Test reading a single stat Ben Gardon
2022-03-10 16:45 ` [PATCH 03/13] selftests: KVM: Wrap memslot IDs in a struct for readability Ben Gardon
2022-03-10 16:45 ` [PATCH 04/13] selftests: KVM: Add memslot parameter to VM vaddr allocation Ben Gardon
2022-03-10 16:45 ` [PATCH 05/13] selftests: KVM: Add memslot parameter to elf_load Ben Gardon
2022-03-10 16:45 ` [PATCH 06/13] selftests: KVM: Improve error message in vm_phy_pages_alloc Ben Gardon
2022-03-10 16:45 ` [PATCH 07/13] selftests: KVM: Add NX huge pages test Ben Gardon
[not found] ` <CABOYuvY8sJgzC2VA=i4gddDu=jZCffFNi5E4G2cJ2B01zg3XcA@mail.gmail.com>
2022-03-10 17:07 ` Ben Gardon
2022-03-10 16:45 ` [PATCH 08/13] KVM: x86/MMU: Factor out updating NX hugepages state for a VM Ben Gardon
2022-03-10 16:45 ` [PATCH 09/13] KVM: x86/MMU: Track NX hugepages on a per-VM basis Ben Gardon
2022-03-10 16:45 ` [PATCH 10/13] KVM: x86/MMU: Allow NX huge pages to be disabled on a per-vm basis Ben Gardon
2022-03-10 16:45 ` [PATCH 11/13] KVM: x86: Fix errant brace in KVM capability handling Ben Gardon
2022-03-10 16:45 ` [PATCH 12/13] KVM: x86/MMU: Require reboot permission to disable NX hugepages Ben Gardon
2022-03-10 16:45 ` [PATCH 13/13] selftests: KVM: Test disabling NX hugepages on a VM Ben Gardon
2022-03-10 17:58 ` [PATCH 00/13] KVM: x86: Add a cap to disable " Sean Christopherson
2022-03-10 19:29 ` Ben Gardon [this message]
2022-03-11 2:19 ` Sean Christopherson
2022-03-15 23:12 ` Ben Gardon
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=CANgfPd9xr5ev7fEiwBVUi89iHkuywq-Ba9zOeCMSTFmLkO243w@mail.gmail.com \
--to=bgardon@google.com \
--cc=daviddunn@google.com \
--cc=dmatlack@google.com \
--cc=jingzhangos@google.com \
--cc=jmattson@google.com \
--cc=junaids@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=seanjc@google.com \
/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;
as well as URLs for NNTP newsgroup(s).