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 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.