From: Janosch Frank <frankja@linux.ibm.com>
To: Christoph Schlameuss <schlameuss@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:20:32 +0200 [thread overview]
Message-ID: <b9528312-4c0d-4a40-940f-82e9af4cca48@linux.ibm.com> (raw)
In-Reply-To: <D3NB8GXIKS75.2AR1GNELFUIBE@linux.ibm.com>
On 8/23/24 3:03 PM, Christoph Schlameuss wrote:
> 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
> +}
>
>
Seems like I'm blind then :)
next prev parent reply other threads:[~2024-08-23 13:20 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
2024-08-23 13:20 ` Janosch Frank [this message]
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=b9528312-4c0d-4a40-940f-82e9af4cca48@linux.ibm.com \
--to=frankja@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@redhat.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=schlameuss@linux.ibm.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