From: Pierre Morel <pmorel@linux.ibm.com>
To: Tony Krowiak <akrowiak@linux.vnet.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Cc: freude@de.ibm.com, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, borntraeger@de.ibm.com,
cohuck@redhat.com, kwankhede@nvidia.com,
bjsdjshi@linux.vnet.ibm.com, pbonzini@redhat.com,
alex.williamson@redhat.com, pmorel@linux.vnet.ibm.com,
alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com,
jjherne@linux.vnet.ibm.com, thuth@redhat.com,
pasic@linux.vnet.ibm.com, berrange@redhat.com,
fiuczy@linux.vnet.ibm.com, buendgen@de.ibm.com
Subject: Re: [PATCH v5 02/13] KVM: s390: refactor crypto initialization
Date: Wed, 16 May 2018 14:17:52 +0200 [thread overview]
Message-ID: <40b5c7d2-a855-f11b-3dbd-afdc8fae268d@linux.ibm.com> (raw)
In-Reply-To: <6835f3b9-c660-fe7c-5583-8706cc1fa732@linux.vnet.ibm.com>
On 16/05/2018 13:14, Tony Krowiak wrote:
> On 05/16/2018 04:51 AM, Pierre Morel wrote:
>> On 07/05/2018 17:11, Tony Krowiak wrote:
>>> This patch refactors the code that initializes the crypto
>>> configuration for a guest. The crypto configuration is contained in
>>> a crypto control block (CRYCB) which is a satellite control block to
>>> our main hardware virtualization control block. The CRYCB is
>>> attached to the main virtualization control block via a CRYCB
>>> designation (CRYCBD) designation field containing the address of
>>> the CRYCB as well as its format.
>>>
>>> Prior to the introduction of AP device virtualization, there was
>>> no need to provide access to or specify the format of the CRYCB for
>>> a guest unless the MSA extension 3 (MSAX3) facility was installed
>>> on the host system. With the introduction of AP device virtualization,
>>> the CRYCB and its format must be made accessible to the guest
>>> regardless of the presence of the MSAX3 facility as long as the
>>> AP instructions are installed on the host.
>>>
>>> Signed-off-by: Tony Krowiak <akrowiak@linux.vnet.ibm.com>
>>> ---
>>> arch/s390/include/asm/kvm_host.h | 1 +
>>> arch/s390/kvm/kvm-s390.c | 64
>>> ++++++++++++++++++++++++++-----------
>>> 2 files changed, 46 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/arch/s390/include/asm/kvm_host.h
>>> b/arch/s390/include/asm/kvm_host.h
>>> index 81cdb6b..5393c4d 100644
>>> --- a/arch/s390/include/asm/kvm_host.h
>>> +++ b/arch/s390/include/asm/kvm_host.h
>>> @@ -255,6 +255,7 @@ struct kvm_s390_sie_block {
>>> __u8 reservede4[4]; /* 0x00e4 */
>>> __u64 tecmc; /* 0x00e8 */
>>> __u8 reservedf0[12]; /* 0x00f0 */
>>> +#define CRYCB_FORMAT_MASK 0x00000003
>>> #define CRYCB_FORMAT1 0x00000001
>>> #define CRYCB_FORMAT2 0x00000003
>>> __u32 crycbd; /* 0x00fc */
>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>> index 1f50de7..99779a6 100644
>>> --- a/arch/s390/kvm/kvm-s390.c
>>> +++ b/arch/s390/kvm/kvm-s390.c
>>> @@ -1875,14 +1875,35 @@ long kvm_arch_vm_ioctl(struct file *filp,
>>> return r;
>>> }
>>>
>>> -static void kvm_s390_set_crycb_format(struct kvm *kvm)
>>> +/*
>>> + * The format of the crypto control block (CRYCB) is specified in
>>> the 3 low
>>> + * order bits of the CRYCB designation (CRYCBD) field as follows:
>>> + * Format 0: Neither the message security assist extension 3
>>> (MSAX3) nor the
>>> + * AP extended addressing (APXA) facility are installed.
>>> + * Format 1: The APXA facility is not installed but the MSAX3
>>> facility is.
>>> + * Format 2: Both the APXA and MSAX3 facilities are installed
>>> + */
>>> +static void kvm_s390_format_crycb(struct kvm *kvm)
>>> {
>>> - kvm->arch.crypto.crycbd = (__u32)(unsigned long)
>>> kvm->arch.crypto.crycb;
>>> + /* Clear the CRYCB format bits - i.e., set format 0 by default */
>>> + kvm->arch.crypto.crycbd &= ~(CRYCB_FORMAT_MASK);
>>> +
>>> + /* Check whether MSAX3 is installed */
>>> + if (!test_kvm_facility(kvm, 76))
>>> + return;
>>>
>>> if (kvm_ap_apxa_installed())
>>> kvm->arch.crypto.crycbd |= CRYCB_FORMAT2;
>>> else
>>> kvm->arch.crypto.crycbd |= CRYCB_FORMAT1;
>>> + one lin
>>> + /* Enable AES/DEA protected key functions by default */
>>> + kvm->arch.crypto.aes_kw = 1;
>>> + kvm->arch.crypto.dea_kw = 1;
>>> + get_random_bytes(kvm->arch.crypto.crycb->aes_wrapping_key_mask,
>>> + sizeof(kvm->arch.crypto.crycb->aes_wrapping_key_mask));
>>> + get_random_bytes(kvm->arch.crypto.crycb->dea_wrapping_key_mask,
>>> + sizeof(kvm->arch.crypto.crycb->dea_wrapping_key_mask));
>>> }
>>>
>>> static u64 kvm_s390_get_initial_cpuid(void)
>>> @@ -1896,19 +1917,17 @@ static u64 kvm_s390_get_initial_cpuid(void)
>>>
>>> static void kvm_s390_crypto_init(struct kvm *kvm)
>>> {
>>> - if (!test_kvm_facility(kvm, 76))
>>> + /*
>>> + * If neither the AP instructions nor the message security assist
>>> + * extension 3 (MSAX3) are installed, there is no need to
>>> initialize a
>>> + * crypto control block (CRYCB) for the guest.
>>> + */
>>> + if (!kvm_ap_instructions_available() && !test_kvm_facility(kvm,
>>> 76))
>>> return;
>>>
>>> kvm->arch.crypto.crycb = &kvm->arch.sie_page2->crycb;
>>> - kvm_s390_set_crycb_format(kvm);
>>
>>
>> For my point of view the all patch can be reduced to putting this
>> call (kvm_s390_set_crycb_format(kvm);) before testing for facility 76.
>>
>> (and setting the format correctly in kvm_s390_set_crycb_format(kvm))
>
> I don't see what that buys us; it will just be reshuffling of the logic.
> The idea here is that all of the code related to formatting the CRYCB for
> use by the guest is contained in the kvm_s390_format_crycb(kvm) function.
> We don't need a CRYCB, however, if the AP instructions are not installed
> and the MSAX3 facility is not installed, so why even call
> kvm_s390_format_crycb(kvm) in that case?
It byes a lot of lines.
I mean that you do exactly the same by only using 3 lines inserted
instead of 65 changes.
No logic change.
>
>>
>>
>>
>>> -
>>> - /* Enable AES/DEA protected key functions by default */
>>> - kvm->arch.crypto.aes_kw = 1;
>>> - kvm->arch.crypto.dea_kw = 1;
>>> - get_random_bytes(kvm->arch.crypto.crycb->aes_wrapping_key_mask,
>>> - sizeof(kvm->arch.crypto.crycb->aes_wrapping_key_mask));
>>> - get_random_bytes(kvm->arch.crypto.crycb->dea_wrapping_key_mask,
>>> - sizeof(kvm->arch.crypto.crycb->dea_wrapping_key_mask));
>>> + kvm->arch.crypto.crycbd = (__u32)(unsigned long)
>>> kvm->arch.crypto.crycb;
>>> + kvm_s390_format_crycb(kvm);
>>> }
>>>
>>> static void sca_dispose(struct kvm *kvm)
>>> @@ -2430,17 +2449,24 @@ void kvm_arch_vcpu_postcreate(struct
>>> kvm_vcpu *vcpu)
>>>
>>> static void kvm_s390_vcpu_crypto_setup(struct kvm_vcpu *vcpu)
>>> {
>>> - if (!test_kvm_facility(vcpu->kvm, 76))
>>> + /*
>>> + * If a crypto control block designation (CRYCBD) has not been
>>> + * initialized
>>> + */
>>> + if (vcpu->kvm->arch.crypto.crycbd == 0)
>>> return;
>>>
>>> - vcpu->arch.sie_block->ecb3 &= ~(ECB3_AES | ECB3_DEA);
>>> + vcpu->arch.sie_block->crycbd = vcpu->kvm->arch.crypto.crycbd;
>>>
>>> - if (vcpu->kvm->arch.crypto.aes_kw)
>>> - vcpu->arch.sie_block->ecb3 |= ECB3_AES;
>>> - if (vcpu->kvm->arch.crypto.dea_kw)
>>> - vcpu->arch.sie_block->ecb3 |= ECB3_DEA;
>>> + /* If MSAX3 is installed, set up protected key support */
>>> + if (test_kvm_facility(vcpu->kvm, 76)) {
>>> + vcpu->arch.sie_block->ecb3 &= ~(ECB3_AES | ECB3_DEA);
>>>
>>> - vcpu->arch.sie_block->crycbd = vcpu->kvm->arch.crypto.crycbd;
>>> + if (vcpu->kvm->arch.crypto.aes_kw)
>>> + vcpu->arch.sie_block->ecb3 |= ECB3_AES;
>>> + if (vcpu->kvm->arch.crypto.dea_kw)
>>> + vcpu->arch.sie_block->ecb3 |= ECB3_DEA;
>>> + }
>>> }
>>>
>>> void kvm_s390_vcpu_unsetup_cmma(struct kvm_vcpu *vcpu)
>>
>>
>
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
next prev parent reply other threads:[~2018-05-16 12:18 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-07 15:11 [PATCH v5 00/13] s390: vfio-ap: guest dedicated crypto adapters Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 01/13] KVM: s390: Interface to test whether APXA installed Tony Krowiak
2018-05-16 10:21 ` Cornelia Huck
2018-05-16 10:45 ` Tony Krowiak
2018-05-17 9:11 ` Harald Freudenberger
2018-05-17 9:44 ` Cornelia Huck
2018-05-07 15:11 ` [PATCH v5 02/13] KVM: s390: refactor crypto initialization Tony Krowiak
2018-05-16 8:51 ` Pierre Morel
2018-05-16 11:14 ` Tony Krowiak
2018-05-16 12:17 ` Pierre Morel [this message]
2018-05-16 12:21 ` Cornelia Huck
2018-05-07 15:11 ` [PATCH v5 03/13] KVM: s390: CPU model support for AP virtualization Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 04/13] s390: vfio-ap: base implementation of VFIO AP device driver Tony Krowiak
2018-05-16 8:21 ` Pierre Morel
2018-05-16 11:29 ` Tony Krowiak
2018-05-16 11:45 ` Tony Krowiak
2018-06-07 8:57 ` Pierre Morel
2018-06-13 7:41 ` Pierre Morel
2018-06-13 7:48 ` Cornelia Huck
2018-06-13 10:54 ` Pierre Morel
2018-06-13 11:14 ` Cornelia Huck
2018-06-13 12:01 ` Pierre Morel
2018-06-13 12:12 ` Cornelia Huck
2018-06-13 12:16 ` Pierre Morel
2018-06-14 13:04 ` Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 05/13] s390: vfio-ap: register matrix device with VFIO mdev framework Tony Krowiak
2018-05-11 17:18 ` Halil Pasic
2018-05-14 19:42 ` Tony Krowiak
2018-05-15 14:17 ` Pierre Morel
2018-05-15 15:16 ` Tony Krowiak
2018-05-15 15:48 ` Halil Pasic
2018-05-15 16:11 ` Tony Krowiak
2018-05-17 7:44 ` Cornelia Huck
2018-05-21 15:13 ` Tony Krowiak
2018-05-22 8:19 ` Cornelia Huck
2018-05-22 21:41 ` Tony Krowiak
2018-05-16 10:42 ` Cornelia Huck
2018-05-16 12:48 ` Tony Krowiak
2018-05-16 12:58 ` Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP matrix Tony Krowiak
2018-05-11 16:08 ` Halil Pasic
2018-05-16 14:29 ` Tony Krowiak
2018-05-16 14:41 ` Pierre Morel
2018-05-21 15:23 ` Tony Krowiak
2018-05-15 14:55 ` Pierre Morel
2018-05-15 16:07 ` Tony Krowiak
2018-05-16 7:48 ` Pierre Morel
2018-05-16 13:12 ` Tony Krowiak
2018-05-16 13:15 ` Pierre Morel
2018-05-16 13:48 ` Tony Krowiak
2018-05-18 8:55 ` Pierre Morel
2018-05-23 14:29 ` Tony Krowiak
2018-05-24 7:46 ` Pierre Morel
2018-05-07 15:11 ` [PATCH v5 07/13] s390: vfio-ap: sysfs interfaces to configure adapters Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 08/13] s390: vfio-ap: sysfs interfaces to configure domains Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 09/13] s390: vfio-ap: sysfs interfaces to configure control domains Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 10/13] s390: vfio-ap: sysfs interface to view matrix mdev matrix Tony Krowiak
2018-05-16 7:55 ` Pierre Morel
2018-05-23 14:38 ` Tony Krowiak
2018-05-24 9:10 ` Pierre Morel
2018-05-30 14:28 ` Tony Krowiak
2018-06-05 12:40 ` Pierre Morel
2018-06-06 14:24 ` Tony Krowiak
2018-06-06 15:10 ` Pierre Morel
2018-06-07 12:53 ` Tony Krowiak
2018-06-07 13:16 ` Halil Pasic
2018-06-07 14:33 ` Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 11/13] KVM: s390: implement mediated device open callback Tony Krowiak
2018-05-16 8:03 ` Pierre Morel
2018-05-23 14:45 ` Tony Krowiak
2018-05-24 9:08 ` Pierre Morel
2018-05-30 14:33 ` Tony Krowiak
2018-06-05 12:19 ` Pierre Morel
2018-06-06 14:28 ` Tony Krowiak
2018-06-06 16:08 ` Pierre Morel
2018-06-06 17:40 ` Pierre Morel
2018-06-07 13:54 ` Tony Krowiak
2018-06-07 15:20 ` Pierre Morel
2018-06-07 16:30 ` Tony Krowiak
2018-06-07 17:15 ` Pierre Morel
2018-06-08 21:59 ` Tony Krowiak
2018-06-11 9:23 ` Pierre Morel
2018-06-11 11:32 ` Halil Pasic
2018-06-11 11:49 ` Janosch Frank
2018-06-11 16:26 ` Tony Krowiak
2018-06-11 16:50 ` Halil Pasic
2018-06-11 16:54 ` Tony Krowiak
2018-06-11 12:50 ` Tony Krowiak
2018-06-11 12:56 ` Tony Krowiak
2018-06-07 13:52 ` Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 12/13] s390: vfio-ap: implement VFIO_DEVICE_GET_INFO ioctl Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 13/13] s390: doc: detailed specifications for AP virtualization Tony Krowiak
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=40b5c7d2-a855-f11b-3dbd-afdc8fae268d@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=akrowiak@linux.vnet.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.vnet.ibm.com \
--cc=berrange@redhat.com \
--cc=bjsdjshi@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=buendgen@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=fiuczy@linux.vnet.ibm.com \
--cc=freude@de.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jjherne@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.vnet.ibm.com \
--cc=pasic@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.vnet.ibm.com \
--cc=schwidefsky@de.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;
as well as URLs for NNTP newsgroup(s).