From: "Christoph Schlameuss" <schlameuss@linux.ibm.com>
To: "Janosch Frank" <frankja@linux.ibm.com>, <kvm@vger.kernel.org>
Cc: <linux-s390@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Shuah Khan" <shuah@kernel.org>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Claudio Imbrenda" <imbrenda@linux.ibm.com>,
"David Hildenbrand" <david@redhat.com>,
"Nina Schoetterl-Glausch" <nsg@linux.ibm.com>
Subject: Re: [PATCH 1/3] selftests: kvm: s390: Add uc_map_unmap VM test case
Date: Fri, 23 Aug 2024 15:03:20 +0200 [thread overview]
Message-ID: <D3NB8GXIKS75.2AR1GNELFUIBE@linux.ibm.com> (raw)
In-Reply-To: <884367dd-fba0-4acd-a614-f657768b662a@linux.ibm.com>
On Fri Aug 23, 2024 at 10:02 AM CEST, Janosch Frank wrote:
> On 8/19/24 6:03 PM, Christoph Schlameuss wrote:
> > On Fri Aug 16, 2024 at 4:29 PM CEST, Janosch Frank wrote:
> >> On 8/15/24 5:45 PM, Christoph Schlameuss wrote:
> >>> Add a test case verifying basic running and interaction of ucontrol VMs.
> >>> Fill the segment and page tables for allocated memory and map memory on
> >>> first access.
> >>>
> >>> * uc_map_unmap
> >>> Store and load data to mapped and unmapped memory and use pic segment
> >>> translation handling to map memory on access.
> >>>
> >>> Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
> >>> ---
> >>> .../selftests/kvm/s390x/ucontrol_test.c | 120 +++++++++++++++++-
> >>> 1 file changed, 119 insertions(+), 1 deletion(-)
> >>>
> >>
> >>> +static void uc_handle_exit_ucontrol(FIXTURE_DATA(uc_kvm) * self)
> >>> +{
> >>> + struct kvm_run *run = self->run;
> >>> +
> >>> + TEST_ASSERT_EQ(KVM_EXIT_S390_UCONTROL, run->exit_reason);
> >>> + switch (run->s390_ucontrol.pgm_code) {
> >>> + case PGM_SEGMENT_TRANSLATION:
> >>> + pr_info("ucontrol pic segment translation 0x%llx\n",
> >>> + run->s390_ucontrol.trans_exc_code);
> >>> + /* map / make additional memory available */
> >>> + struct kvm_s390_ucas_mapping map2 = {
> >>> + .user_addr = (u64)gpa2hva(self, run->s390_ucontrol.trans_exc_code),
> >>> + .vcpu_addr = run->s390_ucontrol.trans_exc_code,
> >>> + .length = VM_MEM_EXT_SIZE,
> >>> + };
> >>> + pr_info("ucas map %p %p 0x%llx\n",
> >>> + (void *)map2.user_addr, (void *)map2.vcpu_addr, map2.length);
> >>> + TEST_ASSERT_EQ(0, ioctl(self->vcpu_fd, KVM_S390_UCAS_MAP, &map2));
> >>> + break;
> >>
> >> Why is this necessary if you fix up the mapping in the test?
> >>
> >
> > This is also used within the uc_skey test to make sure the remap does
> > work after the unmap.
>
> Maybe I'm blind because I'm still recovering but where exactly?
It is literally used in the last line of the test case. Calling uc_handle_exit()
again re-maps previously unmapped memory.
I can try to make that a little bit more obvious.
+ /* unmap and run loop again */
+ TH_LOG("ucas unmap %p %p 0x%llx",
+ (void *)map2.user_addr, (void *)map2.vcpu_addr, map2.length);
+ rc = ioctl(self->vcpu_fd, KVM_S390_UCAS_UNMAP, &map2);
+ ASSERT_EQ(0, rc)
+ TH_LOG("ucas map result %d not expected, %s", rc, strerror(errno));
+ ASSERT_EQ(0, uc_run_once(self));
+ ASSERT_EQ(3, sync_regs->gprs[0]);
+ ASSERT_EQ(KVM_EXIT_S390_UCONTROL, run->exit_reason);
+ ASSERT_EQ(true, uc_handle_exit(self)); // <--- HERE
+}
next prev parent reply other threads:[~2024-08-23 13:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 15:45 [PATCH 0/3] selftests: kvm: s390: Add ucontrol memory selftests Christoph Schlameuss
2024-08-15 15:45 ` [PATCH 1/3] selftests: kvm: s390: Add uc_map_unmap VM test case Christoph Schlameuss
2024-08-16 14:29 ` Janosch Frank
2024-08-19 16:03 ` Christoph Schlameuss
2024-08-23 8:02 ` Janosch Frank
2024-08-23 13:03 ` Christoph Schlameuss [this message]
2024-08-23 13:20 ` Janosch Frank
2024-08-15 15:45 ` [PATCH 2/3] selftests: kvm: s390: Add uc_skey " Christoph Schlameuss
2024-08-16 14:36 ` Janosch Frank
2024-08-19 16:00 ` Christoph Schlameuss
2024-08-23 7:59 ` Janosch Frank
2024-08-30 15:51 ` Christoph Schlameuss
2024-08-15 15:45 ` [PATCH 3/3] selftests: kvm: s390: Verify reject memory region operations for ucontrol VMs Christoph Schlameuss
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=D3NB8GXIKS75.2AR1GNELFUIBE@linux.ibm.com \
--to=schlameuss@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nsg@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
/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