Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9666c15f-a824-0c8e-508d-57d1da147fff@linux.ibm.com>
Date:   Thu, 19 May 2022 11:13:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [PATCH v4 1/2] drivers/s390/char: Add Ultravisor io device
Content-Language: en-US
To:     Heiko Carstens <hca@linux.ibm.com>
Cc:     Steffen Eiden <seiden@linux.ibm.com>, Greg KH <greg@kroah.com>,
        Alexander Gordeev <agordeev@linux.ibm.com>,
        Shuah Khan <shuah@kernel.org>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Claudio Imbrenda <imbrenda@linux.ibm.com>,
        David Hildenbrand <david@redhat.com>,
        Nico Boehr <nrb@linux.ibm.com>, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org, kvm@vger.kernel.org
References: <20220510144724.3321985-1-seiden@linux.ibm.com>
 <20220510144724.3321985-2-seiden@linux.ibm.com> <YoTcxhulemnqiUbC@osiris>
 <48550162-0f8c-4b23-dea4-b9060b24eed9@linux.ibm.com>
 <YoXXjC49xKY/TJ+2@osiris>
From:   Janosch Frank <frankja@linux.ibm.com>
In-Reply-To: <YoXXjC49xKY/TJ+2@osiris>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/19/22 07:37, Heiko Carstens wrote:
> On Wed, May 18, 2022 at 03:45:27PM +0200, Janosch Frank wrote:
>>>> +	  The device is only available if the Ultravisor
>>>> +	  Facility (158) is present.
>>>
>>> Is there a reason why this is default "y"? If you think this should be
>>> compiled into the kernel if used, then why allow to make it a module
>>> at all?
>>> Instead you could get rid of a couple if lines of code.
>>
>> There was a lot of discussion around this already and the "Y" was chosen as
>> auto-loading this is a pain and therefore the SCLP and CHSC-Misc set it to Y
>> and we took that as an example (Steffen spoke to Peter to get guidance).
>>
>> I'm sure that we want the possibility to have this as a module. Personally
>> I'd choose "m" over "y" since the module is only useful for a very small
>> amount of users.
> 
> Why not simply use module_cpu_feature_match() to implement auto module
> loading like we do it for the crypto modules? That would require that
> either the uv facility is represented within elf hwcaps, or
> alternatively the s390 implementation of cpu_feature() needs to be
> changed to work with cpu facilities instead of hwcap bits.
> (see arch/s390/include/asm/cpufeature.h)
> 
> This doesn't look too difficult. Or was there a reason not to go this route?

I'd guess we looked into the wrong direction for auto-load.

We'll look into that for 5.20 but we'll take this patch with the "m" 
tristate for 5.19.

Thanks for the pointer and review.