From: Sean Christopherson <seanjc@google.com> To: Andrew Jones <drjones@redhat.com> Cc: Oliver Upton <oupton@google.com>, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>, Alexandru Elisei <alexandru.elisei@arm.com>, Suzuki K Poulose <suzuki.poulose@arm.com>, Paolo Bonzini <pbonzini@redhat.com>, Jim Mattson <jmattson@google.com> Subject: Re: [PATCH] selftests: KVM: Call ucall_init when setting up in rseq_test Date: Tue, 28 Sep 2021 15:20:50 +0000 [thread overview] Message-ID: <YVMy0uzfSNrUo+Ur@google.com> (raw) In-Reply-To: <20210928072409.ks6b6u3rs7qngije@gator.home> On Tue, Sep 28, 2021, Andrew Jones wrote: > On Mon, Sep 27, 2021 at 08:05:14PM +0000, Sean Christopherson wrote: > > My vote would be to rework arm64's ucall_init() as a prep patch and drop the param > > in the process. There are zero tests that provide a non-NULL value, but that's > > likely because tests that care deliberately defer ucall_init() until after memory > > regions and page tables have been configured. > > > > IMO, arm64's approach is unnecessarily complex (that's a common theme for KVM's > > selftests...). The code attempts to avoid magic numbers by not hardcoding the MMIO > > range, but in doing so makes the end result even more magical, e.g. starting at > > 5/8ths of min(MAX_PA, MAX_VA). > > > > E.g. why not put the ucall MMIO range immediately after the so called "default" > > memory region added at the end of vm_create()? That way the location of the ucall > > range is completely predictable, and while still arbitrary, less magical. > > > > While we do hardcode zero as the guest physical base address, we don't > require tests to use DEFAULT_GUEST_PHY_PAGES for slot0. They only get > that if they use vm_create_default* to create the vm. While trying to > keep the framework flexible for the unit tests does lead to complexity, > I think the ucall mmio address really needs to be something that can move. Rats, I had contradicting information in my reply. Ignore the part about dropping the param. My intended suggestion was to dynamically place the ucall range after the default region, i.e. it would float around, but the relative location is fixed. diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c index 10a8ed691c66..0ec2de586bf7 100644 --- a/tools/testing/selftests/kvm/lib/kvm_util.c +++ b/tools/testing/selftests/kvm/lib/kvm_util.c @@ -315,6 +315,8 @@ struct kvm_vm *vm_create(enum vm_guest_mode mode, uint64_t phy_pages, int perm) vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, phy_pages, 0); + ucall_init(0 + <size of default region>); + return vm; } > It's not part of the test setup, i.e. whatever the unit test wants to > test, it's just part of the framework. It needs to stay out of the way. Sort of. In this specific case, I think it's the tests' responsibility to not stomp over the ucall region as much as it's the framework's responsibility to not select a conflicting range. Arch-agnostic tests _can't_ care about absolute addresses, and we done messed up if we pick a ucall range that is at all interesting/unique on arm64. The problem with the current approach is that it's unnecessarily difficult for either side to do the right thing. The framework should not have to search memory regions, and test writers should be given simple (and documented!) rules for what memory regions are reserved by the framework.
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com> To: Andrew Jones <drjones@redhat.com> Cc: kvm@vger.kernel.org, Marc Zyngier <maz@kernel.org>, Paolo Bonzini <pbonzini@redhat.com>, kvmarm@lists.cs.columbia.edu, Jim Mattson <jmattson@google.com> Subject: Re: [PATCH] selftests: KVM: Call ucall_init when setting up in rseq_test Date: Tue, 28 Sep 2021 15:20:50 +0000 [thread overview] Message-ID: <YVMy0uzfSNrUo+Ur@google.com> (raw) In-Reply-To: <20210928072409.ks6b6u3rs7qngije@gator.home> On Tue, Sep 28, 2021, Andrew Jones wrote: > On Mon, Sep 27, 2021 at 08:05:14PM +0000, Sean Christopherson wrote: > > My vote would be to rework arm64's ucall_init() as a prep patch and drop the param > > in the process. There are zero tests that provide a non-NULL value, but that's > > likely because tests that care deliberately defer ucall_init() until after memory > > regions and page tables have been configured. > > > > IMO, arm64's approach is unnecessarily complex (that's a common theme for KVM's > > selftests...). The code attempts to avoid magic numbers by not hardcoding the MMIO > > range, but in doing so makes the end result even more magical, e.g. starting at > > 5/8ths of min(MAX_PA, MAX_VA). > > > > E.g. why not put the ucall MMIO range immediately after the so called "default" > > memory region added at the end of vm_create()? That way the location of the ucall > > range is completely predictable, and while still arbitrary, less magical. > > > > While we do hardcode zero as the guest physical base address, we don't > require tests to use DEFAULT_GUEST_PHY_PAGES for slot0. They only get > that if they use vm_create_default* to create the vm. While trying to > keep the framework flexible for the unit tests does lead to complexity, > I think the ucall mmio address really needs to be something that can move. Rats, I had contradicting information in my reply. Ignore the part about dropping the param. My intended suggestion was to dynamically place the ucall range after the default region, i.e. it would float around, but the relative location is fixed. diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c index 10a8ed691c66..0ec2de586bf7 100644 --- a/tools/testing/selftests/kvm/lib/kvm_util.c +++ b/tools/testing/selftests/kvm/lib/kvm_util.c @@ -315,6 +315,8 @@ struct kvm_vm *vm_create(enum vm_guest_mode mode, uint64_t phy_pages, int perm) vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, phy_pages, 0); + ucall_init(0 + <size of default region>); + return vm; } > It's not part of the test setup, i.e. whatever the unit test wants to > test, it's just part of the framework. It needs to stay out of the way. Sort of. In this specific case, I think it's the tests' responsibility to not stomp over the ucall region as much as it's the framework's responsibility to not select a conflicting range. Arch-agnostic tests _can't_ care about absolute addresses, and we done messed up if we pick a ucall range that is at all interesting/unique on arm64. The problem with the current approach is that it's unnecessarily difficult for either side to do the right thing. The framework should not have to search memory regions, and test writers should be given simple (and documented!) rules for what memory regions are reserved by the framework. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2021-09-28 15:20 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-23 22:00 [PATCH] selftests: KVM: Call ucall_init when setting up in rseq_test Oliver Upton 2021-09-23 22:00 ` Oliver Upton 2021-09-24 0:09 ` Sean Christopherson 2021-09-24 0:09 ` Sean Christopherson 2021-09-24 0:10 ` Oliver Upton 2021-09-24 0:10 ` Oliver Upton 2021-09-24 6:32 ` Paolo Bonzini 2021-09-24 6:32 ` Paolo Bonzini 2021-09-24 6:47 ` Andrew Jones 2021-09-24 6:47 ` Andrew Jones 2021-09-27 20:05 ` Sean Christopherson 2021-09-27 20:05 ` Sean Christopherson 2021-09-28 7:24 ` Andrew Jones 2021-09-28 7:24 ` Andrew Jones 2021-09-28 15:20 ` Sean Christopherson [this message] 2021-09-28 15:20 ` Sean Christopherson 2021-09-28 15:30 ` Paolo Bonzini 2021-09-28 15:30 ` Paolo Bonzini
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=YVMy0uzfSNrUo+Ur@google.com \ --to=seanjc@google.com \ --cc=alexandru.elisei@arm.com \ --cc=drjones@redhat.com \ --cc=james.morse@arm.com \ --cc=jmattson@google.com \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=maz@kernel.org \ --cc=oupton@google.com \ --cc=pbonzini@redhat.com \ --cc=suzuki.poulose@arm.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: linkBe 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.