On Thu, 29 Mar 2018 14:57:22 -0400 Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> wrote: > On 03/26/2018 04:44 AM, Cornelia Huck wrote: > > On Thu, 15 Mar 2018 15:55:39 +0100 > > Pierre Morel <pmorel@xxxxxxxxxxxxxxxxxx> wrote: > > > >> On 15/03/2018 15:48, Tony Krowiak wrote: > >>> On 03/15/2018 08:26 AM, Pierre Morel wrote: > >>>> On 14/03/2018 19:25, Tony Krowiak wrote: > >>>>> diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig > >>>>> index a3dbd45..4ca9077 100644 > >>>>> --- a/arch/s390/kvm/Kconfig > >>>>> +++ b/arch/s390/kvm/Kconfig > >>>>> @@ -33,6 +33,7 @@ config KVM > >>>>> select HAVE_KVM_INVALID_WAKEUPS > >>>>> select SRCU > >>>>> select KVM_VFIO > >>>>> + select ZCRYPT > >>>> I do not think it is a good solution to *always* enable ZCRYPT > >>>> when we have KVM. > >>> If CONFIG_ZCRYPT is not selected, then the kvm_ap_apxa_installed() > >>> function will not compile > >>> because it calls a zcrypt interface. How would you suggest we make > >>> sure zcrypt interfaces > >>> used in KVM are built if CONFIG_ZCRYPT is not selected? > >> if zcrypt is not configured, I suppose that the KVM code initializaing CRYCB > >> has no use but the function will be called from KVM. > >> So I would do something like: > >> > >> #ifdef ZCRYPT > >> external definitions. > >> #else > >> stubs returning error -ENOZCRYPT (or whatever) > >> #endif > > The kvm code used some kind of detection for crycb before (IIRC it was > > for the key-wrapping stuff). I assume that usage is independent of > > zcrypt driver usage in the host? > A function in kvm-s390.c was replaced with a call to the function in > ap_bus.c that was externalized in patch 2/14. This was done to remove > duplicate code. Since zcrypt is built into the kernel, I didn't think > it would be a problem, but apparently because of the way zcrypt is > configured, it is still possible to remove it from the kernel build. Yes. > > > > So, I think that apxa detection function should be used to s390 > > architecture base code and not be conditional on anything. > I am convinced that the original function from kvm_s390.c should be > restored. That would work as well, but removing the code duplication via moving to s390 architecture code should not be that bad, either. Leaving the decision to the respective maintainers.