mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Janosch Frank <frankja@linux.ibm.com>, linux-kernel@vger.kernel.org
Cc: kvm@vger.kernel.org, thuth@redhat.com, david@redhat.com,
	imbrenda@linux.ibm.com, cohuck@redhat.com,
	linux-s390@vger.kernel.org, gor@linux.ibm.com,
	mihajlov@linux.ibm.com
Subject: Re: [PATCH 1/2] s390: uv: Fix sysfs max number of VCPUs reporting
Date: Tue, 19 Jan 2021 11:19:49 +0100	[thread overview]
Message-ID: <b3d99ee1-864c-c96b-34f8-1eb7d464db03@de.ibm.com> (raw)
In-Reply-To: <945319e9-641b-70ea-0e0b-2e71f73cf086@linux.ibm.com>



On 19.01.21 11:15, Janosch Frank wrote:
> 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@linux.ibm.com>
>>> Fixes: a0f60f8431999 ("s390/protvirt: Add sysfs firmware interface for Ultravisor information")
>>> Cc: stable@vger.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?

I think readability is more important. Maybe add a comment in the structure definition that
explains it?

  reply	other threads:[~2021-01-19 10:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 10:04 [PATCH 0/2] s390: uv: small UV fixes Janosch Frank
2021-01-19 10:04 ` [PATCH 1/2] s390: uv: Fix sysfs max number of VCPUs reporting Janosch Frank
2021-01-19 10:11   ` Christian Borntraeger
2021-01-19 10:15     ` Janosch Frank
2021-01-19 10:19       ` Christian Borntraeger [this message]
2021-01-19 13:11   ` Claudio Imbrenda
2021-01-19 16:19   ` Cornelia Huck
2021-01-19 10:04 ` [PATCH 2/2] s390: mm: Fix secure storage access exception handling Janosch Frank
2021-01-19 10:25   ` Christian Borntraeger
2021-01-19 10:38     ` Janosch Frank
2021-01-19 16:24       ` Cornelia Huck
2021-01-20 13:42     ` Heiko Carstens
2021-01-20 14:39       ` Christian Borntraeger
2021-01-20 15:24         ` Heiko Carstens
2021-01-19 13:09   ` Claudio Imbrenda

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=b3d99ee1-864c-c96b-34f8-1eb7d464db03@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mihajlov@linux.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

all inboxes | Powered by JetHome®