Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Janosch Frank <frankja@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	thuth@redhat.com, seiden@linux.ibm.com, nrb@linux.ibm.com,
	nsg@linux.ibm.com
Subject: Re: [kvm-unit-tests PATCH 2/3] s390x: pv: Test sie entry intercepts and validities
Date: Tue, 21 Feb 2023 10:22:13 +0100	[thread overview]
Message-ID: <95184ea5-7451-934d-8988-54f0eeec99f1@linux.ibm.com> (raw)
In-Reply-To: <20230215180625.53b260a9@p-imbrenda>

On 2/15/23 18:06, Claudio Imbrenda wrote:
> On Wed,  1 Feb 2023 08:48:32 +0000
> Janosch Frank <frankja@linux.ibm.com> wrote:
> 
>> The lowcore is an important part of any s390 cpu so we need to make
>> sure it's always available when we virtualize one. For non-PV guests
>> that would mean ensuring that the lowcore page is read and writable by
>> the guest.
>>
>> For PV guests we additionally need to make sure that the page is owned
>> by the guest as it is only allowed to access them if that's the
>> case. The code 112 SIE intercept tells us if the lowcore pages aren't
>> secure anymore.
>>
>> Let's check if that intercept is reported by SIE if we export the
>> lowcore pages. Additionally check if that's also the case if the guest
>> shares the lowcore which will make it readable to the host but
>> ownership of the page should not change.
>>
>> Also we check for validities in these conditions:
>>       * Manipulated cpu timer
>>       * Double SIE for same vcpu
>>       * Re-use of VCPU handle from another secure configuration
>>       * ASCE re-use
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> 
> looks good, see some questions below
> 
>> ---
[...]
>> +	extern const char SNIPPET_NAME_START(asm, snippet_pv_icpt_vir_timing)[];
>> +	extern const char SNIPPET_NAME_END(asm, snippet_pv_icpt_vir_timing)[];
>> +	extern const char SNIPPET_HDR_START(asm, snippet_pv_icpt_vir_timing)[];
>> +	extern const char SNIPPET_HDR_END(asm, snippet_pv_icpt_vir_timing)[];
>> +	int size_hdr = SNIPPET_HDR_LEN(asm, snippet_pv_icpt_vir_timing);
>> +	int size_gbin = SNIPPET_LEN(asm, snippet_pv_icpt_vir_timing);
>> +
>> +	report_prefix_push("manipulated cpu time");
>> +	snippet_pv_init(&vm, SNIPPET_NAME_START(asm, snippet_pv_icpt_vir_timing),
>> +			SNIPPET_HDR_START(asm, snippet_pv_icpt_vir_timing),
>> +			size_gbin, size_hdr, SNIPPET_UNPACK_OFF);
>> +
>> +	sie(&vm);
>> +	report(vm.sblk->icptcode == ICPT_PV_NOTIFY && vm.sblk->ipa == 0x8302 &&
>> +	       vm.sblk->ipb == 0x50000000 && vm.save_area.guest.grs[5] == 0x44,
>> +	       "stp done");
>> +	vm.sblk->cputm -= 0x280de80000 / 2;
> 
> so you are subtracting half of the value?
> 
> why not vm.sblk->cputm /= 2?
> or just set a fixed (very low) magic value?
> 
> what should happen if the cpu timer is higher instead of lower?

I'll need to do some digging to find out why I used this specific 
procedure. It's been a very long time since I wrote those tests.

[...]

>> +	snippet_pv_init(&vm, SNIPPET_NAME_START(asm, snippet_loop),
>> +			SNIPPET_HDR_START(asm, snippet_loop),
>> +			size_gbin, size_hdr, SNIPPET_UNPACK_OFF);
>> +
>> +	sie_expect_validity(&vm);
>> +	smp_cpu_setup(1, psw);
>> +	smp_cpu_setup(2, psw);
>> +	while (vm.sblk->icptcode != ICPT_VALIDITY) { mb(); }
> 
> maybe put the mb(); in a separate line

Can do

> 
>> +	/* Yes I know this is not reliable as one cpu might overwrite it */
> 
> the wording in this comment could be improved

How about:
This might not be fully reliable but it should be sufficient for our 
current goals.

[...]

>> +	report_prefix_push("shared");
>> +	sie(&vm);
>> +	/* Guest indicates that it has shared the new lowcore */
>> +	report(vm.sblk->icptcode == ICPT_PV_NOTIFY && vm.sblk->ipa == 0x8302 &&
>> +	       vm.sblk->ipb == 0x50000000 && vm.save_area.guest.grs[5] == 0x44,
>> +	       "intercept values");
>> +
>> +	uv_export(vm.sblk->mso + lc_off);
>> +	uv_export(vm.sblk->mso + lc_off + PAGE_SIZE);
> 
> why are you not testing both pages individually here, like you did
> above?

Hmm, I don't think there was a reason behind this. I'll add it.

[...]

  reply	other threads:[~2023-02-21  9:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01  8:48 [kvm-unit-tests PATCH 0/3] s390x: Add PV SIE intercepts and ipl tests Janosch Frank
2023-02-01  8:48 ` [kvm-unit-tests PATCH 1/3] lib: s390x: Introduce UV validity function Janosch Frank
2023-02-01  8:48 ` [kvm-unit-tests PATCH 2/3] s390x: pv: Test sie entry intercepts and validities Janosch Frank
2023-02-15 17:06   ` Claudio Imbrenda
2023-02-21  9:22     ` Janosch Frank [this message]
2023-02-28 17:19       ` Claudio Imbrenda
2023-02-01  8:48 ` [kvm-unit-tests PATCH 3/3] s390x: pv: Add IPL reset tests Janosch Frank
2023-02-17 16:42   ` Claudio Imbrenda
2023-02-21  9:26     ` Janosch Frank
2023-02-28 17:20       ` Claudio Imbrenda

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=95184ea5-7451-934d-8988-54f0eeec99f1@linux.ibm.com \
    --to=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=nrb@linux.ibm.com \
    --cc=nsg@linux.ibm.com \
    --cc=seiden@linux.ibm.com \
    --cc=thuth@redhat.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: 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