public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, cohuck@redhat.com,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	frankja@linux.ibm.com, akrowiak@linux.ibm.com,
	borntraeger@de.ibm.com, schwidefsky@de.ibm.com,
	heiko.carstens@de.ibm.com
Subject: Re: [PATCH v2 3/5] KVM: s390: vsie: Allow support for a host without AP
Date: Thu, 23 Aug 2018 08:52:57 +0200	[thread overview]
Message-ID: <8d506740-9228-a5f7-30ad-4bd181d4385a@linux.ibm.com> (raw)
In-Reply-To: <beb38451-8ec9-59c7-2e51-f9a065b769bf@redhat.com>

On 22/08/2018 19:06, David Hildenbrand wrote:
> On 22.08.2018 18:51, Pierre Morel wrote:
>> Currently the CRYCB format used in the host for the
>> shadowed CRYCB is FORMAT2 while no check is done if
>> AP instructions are supported in the host.
>>
>> We better use the format the host calculated for the
>> guest 1 as the host already tested it against its
>> facility set.
>>
>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>> ---
>>   arch/s390/kvm/vsie.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
>> index 56a9d47..0b12916 100644
>> --- a/arch/s390/kvm/vsie.c
>> +++ b/arch/s390/kvm/vsie.c
>> @@ -154,6 +154,7 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>>   	const u32 crycb_addr = crycbd_o & 0x7ffffff8U;
>>   	unsigned long *b1, *b2;
>>   	u8 ecb3_flags;
>> +	unsigned long g1_fmt;
>>   
>>   	scb_s->crycbd = 0;
>>   	if (!(crycbd_o == CRYCB_FORMAT1))
>> @@ -180,8 +181,8 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>>   		return set_validity_icpt(scb_s, 0x0035U);
>>   
>>   	scb_s->ecb3 |= ecb3_flags;
>> -	scb_s->crycbd = ((__u32)(__u64) &vsie_page->crycb) | CRYCB_FORMAT1 |
>> -			CRYCB_FORMAT2;
>> +	g1_fmt = vcpu->arch.sie_block->crycbd & 0x03;
>> +	scb_s->crycbd = ((__u32)(__u64) &vsie_page->crycb) | g1_fmt;
>>   
>>   	/* xor both blocks in one run */
>>   	b1 = (unsigned long *) vsie_page->crycb.dea_wrapping_key_mask;
>>
> 
> This is wrong. I remember that with APXA, if FORMAT2 is available, we
> should always use FORMAT2. That's why we explicitly convert it here.
> 

You are right if FORMAT2 is available we should use FORMAT2
but the intention here is to use what KVM crypto init function did,
assuming it did the right thing.

Eventually we are running on a host without AP and we should use FORMAT1.

Isn't it correct?

Regards,
Pierre


-- 
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany

  parent reply	other threads:[~2018-08-23  6:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-22 16:51 [PATCH v2 0/5] KVM: s390: vsie: Consolidate CRYCB validation Pierre Morel
2018-08-22 16:51 ` [PATCH v2 1/5] KVM: s390: vsie: BUG correction by shadow_crycb Pierre Morel
2018-08-22 16:53   ` David Hildenbrand
2018-08-23  6:40     ` Pierre Morel
2018-08-23  7:27     ` Cornelia Huck
2018-08-23  8:03       ` Pierre Morel
2018-08-23  8:02     ` Janosch Frank
2018-08-23  8:08       ` Pierre Morel
2018-08-22 16:51 ` [PATCH v2 2/5] KVM: s390: vsie: Only accept FORMAT1 CRYCB for guest2 Pierre Morel
2018-08-22 16:55   ` David Hildenbrand
2018-08-23  7:42     ` Pierre Morel
2018-08-22 16:51 ` [PATCH v2 3/5] KVM: s390: vsie: Allow support for a host without AP Pierre Morel
2018-08-22 17:06   ` David Hildenbrand
2018-08-23  6:44     ` Pierre Morel
2018-08-23  7:15       ` David Hildenbrand
2018-08-23  7:54         ` Pierre Morel
2018-08-23  6:52     ` Pierre Morel [this message]
2018-08-22 16:51 ` [PATCH v2 4/5] KVM: s390: vsie: Always test the crycbd for NULL Pierre Morel
2018-08-22 17:07   ` David Hildenbrand
2018-08-23  6:57     ` Pierre Morel
2018-08-22 16:51 ` [PATCH v2 5/5] KVM: s390: vsie: Do the CRYCB validation first Pierre Morel
2018-08-22 17:15   ` David Hildenbrand
2018-08-23  7:17     ` Pierre Morel
2018-08-23  7:31       ` David Hildenbrand
2018-08-23  8:01         ` Pierre Morel
2018-08-23  8:34           ` Janosch Frank
2018-08-23  8:40             ` David Hildenbrand

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=8d506740-9228-a5f7-30ad-4bd181d4385a@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=schwidefsky@de.ibm.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