public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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 :)

  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