From: Sean Christopherson <seanjc@google.com>
To: Peter Xu <peterx@redhat.com>
Cc: David Matlack <dmatlack@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Ben Gardon <bgardon@google.com>, Oliver Upton <oupton@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Andrew Jones <drjones@redhat.com>,
"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>
Subject: Re: [PATCH v2 10/10] KVM: selftests: Add option to run dirty_log_perf_test vCPUs in L2
Date: Wed, 18 May 2022 15:24:36 +0000 [thread overview]
Message-ID: <YoUPtB0KtRuWl4p7@google.com> (raw)
In-Reply-To: <YoT5/TRyA/QKTsqL@xz-m1.local>
On Wed, May 18, 2022, Peter Xu wrote:
> On Tue, May 17, 2022 at 04:20:31PM -0400, Peter Xu wrote:
> > On Tue, May 17, 2022 at 07:05:24PM +0000, David Matlack wrote:
> > > +uint64_t perf_test_nested_pages(int nr_vcpus)
> > > +{
> > > + /*
> > > + * 513 page tables to identity-map the L2 with 1G pages, plus a few
> > > + * pages per-vCPU for data structures such as the VMCS.
> > > + */
> > > + return 513 + 10 * nr_vcpus;
> >
> > Shouldn't that 513 magic value be related to vm->max_gfn instead (rather
> > than assuming all hosts have 39 bits PA)?
> >
> > If my math is correct, it'll require 1GB here just for the l2->l1 pgtables
> > on a 5-level host to run this test nested. So I had a feeling we'd better
> > still consider >4 level hosts some day very soon.. No strong opinion, as
> > long as this test is not run by default.
>
> I had a feeling that when I said N level I actually meant N-1 level in all
> above, since 39 bits are for 3 level not 4 level?..
>
> Then it's ~512GB pgtables on 5 level? If so I do think we'd better have a
> nicer way to do this identity mapping..
Agreed, mapping all theoretically possible gfns into L2 is doomed to fail for
larger MAXPHYADDR systems.
Page table allocations are currently hardcoded to come from memslot0. memslot0
is required to be in lower DRAM, and thus tops out at ~3gb for all intents and
purposes because we need to leave room for the xAPIC.
And I would strongly prefer not to plumb back the ability to specificy an alternative
memslot for page table allocations, because except for truly pathological tests that
functionality is unnecessary and pointless complexity.
> I don't think it's very hard - walk the mem regions in kvm_vm.regions
> should work for us?
Yeah. Alternatively, The test can identity map all of memory <4gb and then also
map "guest_test_phys_mem - guest_num_pages". I don't think there's any other memory
to deal with, is there?
next prev parent reply other threads:[~2022-05-18 15:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-17 19:05 [PATCH v2 00/10] KVM: selftests: Add nested support to dirty_log_perf_test David Matlack
2022-05-17 19:05 ` [PATCH v2 01/10] KVM: selftests: Replace x86_page_size with PG_LEVEL_XX David Matlack
2022-05-17 20:26 ` Peter Xu
2022-05-17 19:05 ` [PATCH v2 02/10] KVM: selftests: Add option to create 2M and 1G EPT mappings David Matlack
2022-05-17 20:27 ` Peter Xu
2022-05-17 19:05 ` [PATCH v2 03/10] KVM: selftests: Drop stale function parameter comment for nested_map() David Matlack
2022-05-17 19:05 ` [PATCH v2 04/10] KVM: selftests: Refactor nested_map() to specify target level David Matlack
2022-05-17 19:05 ` [PATCH v2 05/10] KVM: selftests: Move VMX_EPT_VPID_CAP_AD_BITS to vmx.h David Matlack
2022-05-17 19:05 ` [PATCH v2 06/10] KVM: selftests: Add a helper to check EPT/VPID capabilities David Matlack
2022-05-17 19:05 ` [PATCH v2 07/10] KVM: selftests: Link selftests directly with lib object files David Matlack
2022-05-17 19:05 ` [PATCH v2 08/10] KVM: selftests: Drop unnecessary rule for $(LIBKVM_OBJS) David Matlack
2022-05-17 20:21 ` Peter Xu
2022-05-18 17:18 ` David Matlack
2022-05-17 19:05 ` [PATCH v2 09/10] KVM: selftests: Clean up LIBKVM files in Makefile David Matlack
2022-05-17 19:05 ` [PATCH v2 10/10] KVM: selftests: Add option to run dirty_log_perf_test vCPUs in L2 David Matlack
2022-05-17 20:20 ` Peter Xu
2022-05-18 13:51 ` Peter Xu
2022-05-18 15:24 ` Sean Christopherson [this message]
2022-05-18 16:12 ` David Matlack
2022-05-18 16:37 ` Sean Christopherson
2022-05-20 22:01 ` David Matlack
2022-05-20 22:49 ` David Matlack
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=YoUPtB0KtRuWl4p7@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=drjones@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=vkuznets@redhat.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