All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
From: Ricardo Koller <ricarkol@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: drjones@redhat.com, kvm@vger.kernel.org, maz@kernel.org,
	Andrew Jones <andrew.jones@linux.dev>,
	axelrasmussen@google.com, bgardon@google.com,
	dmatlack@google.com, pbonzini@redhat.com,
	kvmarm@lists.cs.columbia.edu
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
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2022-08-23 23:38 UTC|newest]

Thread overview: 56+ 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 ` Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 01/13] KVM: selftests: Add a userfaultfd library Ricardo Koller
2022-06-24 21:32   ` Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 02/13] KVM: selftests: aarch64: Add virt_get_pte_hva library function Ricardo Koller
2022-06-24 21:32   ` Ricardo Koller
2022-07-12  9:12   ` Andrew Jones
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-06-24 21:32   ` Ricardo Koller
2022-07-12  9:13   ` Andrew Jones
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-06-24 21:32   ` Ricardo Koller
2022-07-12  9:33   ` Andrew Jones
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-06-24 21:32   ` Ricardo Koller
2022-07-12  9:35   ` Andrew Jones
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-06-24 21:32   ` Ricardo Koller
2022-07-12  9:40   ` Andrew Jones
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-06-24 21:32   ` Ricardo Koller
2022-07-12  9:46   ` Andrew Jones
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   ` Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 09/13] KVM: selftests: aarch64: Add aarch64/page_fault_test Ricardo Koller
2022-06-24 21:32   ` Ricardo Koller
2022-06-28 23:43   ` Oliver Upton
2022-06-28 23:43     ` Oliver Upton
2022-06-29  1:32     ` Ricardo Koller
2022-06-29  1:32       ` Ricardo Koller
2022-07-21  1:29   ` Sean Christopherson
2022-07-21  1:29     ` Sean Christopherson
2022-07-22 17:19     ` Ricardo Koller
2022-07-22 17:19       ` Ricardo Koller
2022-07-22 18:20       ` Sean Christopherson
2022-07-22 18:20         ` Sean Christopherson
2022-07-23  8:22         ` Andrew Jones
2022-07-23  8:22           ` Andrew Jones
2022-07-26 18:15           ` Sean Christopherson
2022-07-26 18:15             ` Sean Christopherson
2022-08-23 23:37             ` Ricardo Koller [this message]
2022-08-23 23:37               ` Ricardo Koller
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   ` Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 11/13] KVM: selftests: aarch64: Add dirty logging " Ricardo Koller
2022-06-24 21:32   ` Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 12/13] KVM: selftests: aarch64: Add readonly memslot " Ricardo Koller
2022-06-24 21:32   ` Ricardo Koller
2022-06-24 21:32 ` [PATCH v4 13/13] KVM: selftests: aarch64: Add mix of " Ricardo Koller
2022-06-24 21:32   ` 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 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.