linux-kernel - Re: [PATCH 1/2] s390: uv: Fix sysfs max number of VCPUs reporting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Jan 2021 11:15:53 +0100
From:   Janosch Frank <frankja@...ux.ibm.com>
To:     Christian Borntraeger <borntraeger@...ibm.com>,
        linux-kernel@...r.kernel.org
Cc:     kvm@...r.kernel.org, thuth@...hat.com, david@...hat.com,
        imbrenda@...ux.ibm.com, cohuck@...hat.com,
        linux-s390@...r.kernel.org, gor@...ux.ibm.com,
        mihajlov@...ux.ibm.com
Subject: Re: [PATCH 1/2] s390: uv: Fix sysfs max number of VCPUs reporting

On 1/19/21 11:11 AM, Christian Borntraeger wrote:
> 
> 
> On 19.01.21 11:04, Janosch Frank wrote:
>> The number reported by the query is N-1 and I think people reading the
>> sysfs file would expect N instead. For users creating VMs there's no
>> actual difference because KVM's limit is currently below the UV's
>> limit.
>>
>> The naming of the field is a bit misleading. Number in this context is
>> used like ID and starts at 0. The query field denotes the maximum
>> number that can be put into the VCPU number field in the "create
>> secure CPU" UV call.
>>
>> Signed-off-by: Janosch Frank <frankja@...ux.ibm.com>
>> Fixes: a0f60f8431999 ("s390/protvirt: Add sysfs firmware interface for Ultravisor information")
>> Cc: stable@...r.kernel.org
>> ---
>>  arch/s390/boot/uv.c        | 2 +-
>>  arch/s390/include/asm/uv.h | 4 ++--
>>  arch/s390/kernel/uv.c      | 2 +-
>>  3 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/s390/boot/uv.c b/arch/s390/boot/uv.c
>> index a15c033f53ca..afb721082989 100644
>> --- a/arch/s390/boot/uv.c
>> +++ b/arch/s390/boot/uv.c
>> @@ -35,7 +35,7 @@ void uv_query_info(void)
>>  		uv_info.guest_cpu_stor_len = uvcb.cpu_stor_len;
>>  		uv_info.max_sec_stor_addr = ALIGN(uvcb.max_guest_stor_addr, PAGE_SIZE);
>>  		uv_info.max_num_sec_conf = uvcb.max_num_sec_conf;
>> -		uv_info.max_guest_cpus = uvcb.max_guest_cpus;
>> +		uv_info.max_guest_cpu_id = uvcb.max_guest_cpu_num;
>>  	}
>>  
>>  #ifdef CONFIG_PROTECTED_VIRTUALIZATION_GUEST
>> diff --git a/arch/s390/include/asm/uv.h b/arch/s390/include/asm/uv.h
>> index 0325fc0469b7..c484c95ea142 100644
>> --- a/arch/s390/include/asm/uv.h
>> +++ b/arch/s390/include/asm/uv.h
>> @@ -96,7 +96,7 @@ struct uv_cb_qui {
>>  	u32 max_num_sec_conf;
>>  	u64 max_guest_stor_addr;
>>  	u8  reserved88[158 - 136];
>> -	u16 max_guest_cpus;
>> +	u16 max_guest_cpu_num;
> 
> I think it would read better if we name this also max_guest_cpu_id.
> Otherwise this looks good.
> 

Yes, but I wanted to have the same name as in the specification.
So, what do we value more?



Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)