linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, kvm@vger.kernel.org
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	borntraeger@de.ibm.com, frankja@linux.ibm.com, cohuck@redhat.com,
	thuth@redhat.com, imbrenda@linux.ibm.com, hca@linux.ibm.com,
	gor@linux.ibm.com, wintera@linux.ibm.com, seiden@linux.ibm.com,
	nrb@linux.ibm.com
Subject: Re: [PATCH v8 2/2] s390x: KVM: resetting the Topology-Change-Report
Date: Wed, 4 May 2022 10:05:30 +0200	[thread overview]
Message-ID: <a76353f4-9bad-ba8d-a899-4b0fbdc9ef5a@linux.ibm.com> (raw)
In-Reply-To: <22f7742e-c009-c53b-8f14-34156ea1d135@redhat.com>



On 4/28/22 15:50, David Hildenbrand wrote:
> On 20.04.22 13:34, Pierre Morel wrote:
>> During a subsystem reset the Topology-Change-Report is cleared.
>> Let's give userland the possibility to clear the MTCR in the case
>> of a subsystem reset.
>>
>> To migrate the MTCR, let's give userland the possibility to
>> query the MTCR state.
>>
>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>> ---
>>   arch/s390/include/uapi/asm/kvm.h |   9 +++
>>   arch/s390/kvm/kvm-s390.c         | 103 +++++++++++++++++++++++++++++++
>>   2 files changed, 112 insertions(+)
>>
>> diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
>> index 7a6b14874d65..bb3df6d49f27 100644
>> --- a/arch/s390/include/uapi/asm/kvm.h
>> +++ b/arch/s390/include/uapi/asm/kvm.h
>> @@ -74,6 +74,7 @@ struct kvm_s390_io_adapter_req {
>>   #define KVM_S390_VM_CRYPTO		2
>>   #define KVM_S390_VM_CPU_MODEL		3
>>   #define KVM_S390_VM_MIGRATION		4
>> +#define KVM_S390_VM_CPU_TOPOLOGY	5
>>   
>>   /* kvm attributes for mem_ctrl */
>>   #define KVM_S390_VM_MEM_ENABLE_CMMA	0
>> @@ -171,6 +172,14 @@ struct kvm_s390_vm_cpu_subfunc {
>>   #define KVM_S390_VM_MIGRATION_START	1
>>   #define KVM_S390_VM_MIGRATION_STATUS	2
>>   
>> +/* kvm attributes for cpu topology */
>> +#define KVM_S390_VM_CPU_TOPO_MTR_CLEAR	0
>> +#define KVM_S390_VM_CPU_TOPO_MTR_SET	1
>> +
>> +struct kvm_s390_cpu_topology {
>> +	__u16 mtcr;
>> +};
> 
> Just wondering:
> 
> 1) Do we really need a struct for that
> 2) Do we want to leave some room for later expansion?

Yes it is the goal, if we want to report more topology information for 
the case the vCPUs are not pin on the real CPUs.
In this case I think we need to report more information on the vCPU 
topology to the guest.
For now I explicitly limited the case to pinned vCPUs.

But the change from a u16 to a structure can be done at that moment.

> 
>> +
>>   /* for KVM_GET_REGS and KVM_SET_REGS */
>>   struct kvm_regs {
>>   	/* general purpose regs for s390 */
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 925ccc59f283..755f325c9e70 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -1756,6 +1756,100 @@ static int kvm_s390_sca_set_mtcr(struct kvm *kvm)
>>   	return 0;
>>   }
>>   
>> +/**
>> + * kvm_s390_sca_clear_mtcr
>> + * @kvm: guest KVM description
>> + *
>> + * Is only relevant if the topology facility is present,
>> + * the caller should check KVM facility 11
>> + *
>> + * Updates the Multiprocessor Topology-Change-Report to signal
>> + * the guest with a topology change.
>> + */
>> +static int kvm_s390_sca_clear_mtcr(struct kvm *kvm)
>> +{
>> +	struct bsca_block *sca = kvm->arch.sca;
>> +	struct kvm_vcpu *vcpu;
>> +	int val;
>> +
>> +	vcpu = kvm_s390_get_first_vcpu(kvm);
>> +	if (!vcpu)
>> +		return -ENODEV;
> 
> It would be cleaner to have ipte_lock/ipte_unlock variants that are
> independent of a vcpu.
> 
> Instead of checking for "vcpu->arch.sie_block->eca & ECA_SII" we might
> just check for sclp.has_siif. Everything else that performs the
> lock/unlock should be contained in "struct kvm" directly, unless I am
> missing something.

No you are right, ipte_lock/unlock are independent of the vcpu.
I already had a patch on this but I did not think about sclp.has_siif 
and it was still heavy.

> 
> [...]
> 
>> +
>> +static int kvm_s390_get_topology(struct kvm *kvm, struct kvm_device_attr *attr)
>> +{
>> +	struct kvm_s390_cpu_topology *topology;
>> +	int ret = 0;
>> +
>> +	if (!test_kvm_facility(kvm, 11))
>> +		return -ENXIO;
>> +
>> +	topology = kzalloc(sizeof(*topology), GFP_KERNEL);
>> +	if (!topology)
>> +		return -ENOMEM;
> 
> I'm confused. We're allocating a __u16 to then free it again below? Why
> not simply use a value on the stack like in kvm_s390_vm_get_migration()?

comes from the idea to bring up more information.
But done like this it has no point.


> 
> 
> 
> u16 mtcr;
> ...
> mtcr = kvm_s390_sca_get_mtcr(kvm);
> 
> if (copy_to_user((void __user *)attr->addr, &mtcr, sizeof(mtcr)))
> 	return -EFAULT;
> return 0;

yes, thanks.

> 
> 
> 
>> +
>> +	topology->mtcr =  kvm_s390_sca_get_mtcr(kvm);
> 
> s/  / /

yes too

> 
>> +	if (copy_to_user((void __user *)attr->addr, topology,
>> +			 sizeof(struct kvm_s390_cpu_topology)))
>> +		ret = -EFAULT;
>> +
>> +	kfree(topology);
>> +	return ret;
>> +}
>> +
> 
> 


Thanks a lot David,

Regards,
Pierre

-- 
Pierre Morel
IBM Lab Boeblingen

      reply	other threads:[~2022-05-04  8:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 11:34 [PATCH v8 0/2] s390x: KVM: CPU Topology Pierre Morel
2022-04-20 11:34 ` [PATCH v8 1/2] s390x: KVM: guest support for topology function Pierre Morel
2022-04-20 12:05   ` Heiko Carstens
2022-04-20 12:13     ` Pierre Morel
2022-04-20 13:22     ` Claudio Imbrenda
2022-04-20 18:25       ` Heiko Carstens
2022-04-20 18:31         ` Pierre Morel
2022-04-20 11:34 ` [PATCH v8 2/2] s390x: KVM: resetting the Topology-Change-Report Pierre Morel
2022-04-21  6:40   ` kernel test robot
2022-04-21  6:41   ` kernel test robot
2022-04-28 13:50   ` David Hildenbrand
2022-05-04  8:05     ` Pierre Morel [this message]

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=a76353f4-9bad-ba8d-a899-4b0fbdc9ef5a@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@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=nrb@linux.ibm.com \
    --cc=seiden@linux.ibm.com \
    --cc=thuth@redhat.com \
    --cc=wintera@linux.ibm.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).