From: Ricardo Koller <ricarkol@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Andrew Jones <andrew.jones@linux.dev>,
kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
drjones@redhat.com, maz@kernel.org, bgardon@google.com,
dmatlack@google.com, pbonzini@redhat.com,
axelrasmussen@google.com
Subject: Re: [PATCH v4 09/13] KVM: selftests: aarch64: Add aarch64/page_fault_test
Date: Tue, 23 Aug 2022 16:37:53 -0700 [thread overview]
Message-ID: <YwVk0a/FTfYS1nNf@google.com> (raw)
In-Reply-To: <YuAvQ0C8ZprtJ4US@google.com>
On Tue, Jul 26, 2022 at 06:15:31PM +0000, Sean Christopherson wrote:
> On Sat, Jul 23, 2022, Andrew Jones wrote:
> > On Fri, Jul 22, 2022 at 06:20:07PM +0000, Sean Christopherson wrote:
> > > On Fri, Jul 22, 2022, Ricardo Koller wrote:
> > > > What about dividing the changes in two.
> > > >
> > > > 1. Will add the struct to "__vm_create()" as part of this
> > > > series, and then use it in this commit. There's only one user
> > > >
> > > > dirty_log_test.c: vm = __vm_create(mode, 1, extra_mem_pages);
> > > >
> > > > so that would avoid having to touch every test as part of this patchset.
> > > >
> > > > 2. I can then send another series to add support for all the other
> > > > vm_create() functions.
> > > >
> > > > Alternatively, I can send a new series that does 1 and 2 afterwards.
> > > > WDYT?
> > >
> > > Don't do #2, ever. :-) The intent of having vm_create() versus is __vm_create()
> > > is so that tests that don't care about things like backing pages don't have to
> > > pass in extra params. I very much want to keep that behavior, i.e. I don't want
> > > to extend vm_create() at all. IMO, adding _anything_ is a slippery slope, e.g.
> > > why are the backing types special enough to get a param, but thing XYZ isn't?
> > >
> > > Thinking more, the struct idea probably isn't going to work all that well. It
> > > again puts the selftests into a state where it becomes difficult to control one
> > > setting and ignore the rest, e.g. the dirty_log_test and anything else with extra
> > > pages suddenly has to care about the backing type for page tables and code.
> > >
> > > Rather than adding a struct, what about extending the @mode param? We already
> > > have vm_mem_backing_src_type, we just need a way to splice things together. There
> > > are a total of four things we can control: primary mode, and then code, data, and
> > > page tables backing types.
> > >
> > > So, turn @mode into a uint32_t and carve out 8 bits for each of those four "modes".
> > > The defaults Just Work because VM_MEM_SRC_ANONYMOUS==0.
> >
> > Hi Sean,
> >
> > How about merging both proposals and turn @mode into a struct and pass
> > around a pointer to it? Then, when calling something that requires @mode,
> > if @mode is NULL, the called function would use vm_arch_default_mode()
> > to get a pointer to the arch-specific default mode struct.
>
> One tweak: rather that use @NULL as a magic param, #define VM_MODE_DEFAULT to
> point at a global struct, similar to what is already done for __aarch64__.
>
> E.g.
>
> __vm_create(VM_MODE_DEFAULT, nr_runnable_vcpus, 0);
>
> does a much better job of self-documenting its behavior than this:
>
> __vm_create(NULL, nr_runnable_vcpus, 0);
>
> > If a test needs to modify the parameters then it can construct a mode struct
> > from scratch or start with a copy of the default. As long as all members of
> > the struct representing parameters, such as backing type, have defaults
> > mapped to zero for the struct members, then we shouldn't be adding any burden
> > to users that don't care about other parameters (other than ensuring their
> > @mode struct was zero initialized).
>
> I was hoping to avoid forcing tests to build a struct, but looking at all the
> existing users, they either use for_each_guest_mode() or just pass VM_MODE_DEFAULT,
> so in practice it's a complete non-issue.
>
> The page fault usage will likely be similar, e.g. programatically generate the set
> of combinations to test.
>
> So yeah, let's try the struct approach.
Thank you both for the suggestions.
About to send v5 with the suggested changes, with a slight modification.
V5 adds "struct kvm_vm_mem_params" which includes a "guest mode" field.
The suggestion was to overload "guest mode". What I have doesn't change
the meaning of "guest mode", and just keeps everything dealing with
"guest mode" the same (like guest_mode.c).
The main changes are:
1. adding a struct kvm_vm_mem_params that defines the memory layout:
-struct kvm_vm *____vm_create(enum vm_guest_mode mode, uint64_t nr_pages);
+struct kvm_vm *____vm_create(struct kvm_vm_mem_params *mem_params);
2. adding memslot vm->memslot.[code|pt|data] and change all allocators
to use the right memslot, e.g.,: lib/elf should use the code memslot.
3. change the new page_fault_test.c setup_memslot() accordingly (much
nicer).
Let me know what you think.
Thanks!
Ricardo
next prev parent reply other threads:[~2022-08-23 23:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 21:32 [PATCH v4 00/13] KVM: selftests: Add aarch64/page_fault_test Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 01/13] KVM: selftests: Add a userfaultfd library Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 02/13] KVM: selftests: aarch64: Add virt_get_pte_hva library function Ricardo Koller
2022-07-12 9:12 ` Andrew Jones
2022-06-24 21:32 ` [PATCH v4 03/13] KVM: selftests: Add vm_alloc_page_table_in_memslot " Ricardo Koller
2022-07-12 9:13 ` Andrew Jones
2022-06-24 21:32 ` [PATCH v4 04/13] KVM: selftests: aarch64: Export _virt_pg_map with a pt_memslot arg Ricardo Koller
2022-07-12 9:33 ` Andrew Jones
2022-06-24 21:32 ` [PATCH v4 05/13] KVM: selftests: Add missing close and munmap in __vm_mem_region_delete Ricardo Koller
2022-07-12 9:35 ` Andrew Jones
2022-06-24 21:32 ` [PATCH v4 06/13] KVM: selftests: Add vm_mem_region_get_src_fd library function Ricardo Koller
2022-07-12 9:40 ` Andrew Jones
2022-06-24 21:32 ` [PATCH v4 07/13] KVM: selftests: aarch64: Construct DEFAULT_MAIR_EL1 using sysreg.h macros Ricardo Koller
2022-07-12 9:46 ` Andrew Jones
2022-06-24 21:32 ` [PATCH v4 08/13] tools: Copy bitfield.h from the kernel sources Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 09/13] KVM: selftests: aarch64: Add aarch64/page_fault_test Ricardo Koller
2022-06-28 23:43 ` Oliver Upton
2022-06-29 1:32 ` Ricardo Koller
2022-07-21 1:29 ` Sean Christopherson
2022-07-22 17:19 ` Ricardo Koller
2022-07-22 18:20 ` Sean Christopherson
2022-07-23 8:22 ` Andrew Jones
2022-07-26 18:15 ` Sean Christopherson
2022-08-23 23:37 ` Ricardo Koller [this message]
2022-06-24 21:32 ` [PATCH v4 10/13] KVM: selftests: aarch64: Add userfaultfd tests into page_fault_test Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 11/13] KVM: selftests: aarch64: Add dirty logging " Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 12/13] KVM: selftests: aarch64: Add readonly memslot " Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 13/13] KVM: selftests: aarch64: Add mix of " Ricardo Koller
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=YwVk0a/FTfYS1nNf@google.com \
--to=ricarkol@google.com \
--cc=andrew.jones@linux.dev \
--cc=axelrasmussen@google.com \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=drjones@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=maz@kernel.org \
--cc=pbonzini@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).