All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christoph Schlameuss" <schlameuss@linux.ibm.com>
To: "Janosch Frank" <frankja@linux.ibm.com>, <kvm@vger.kernel.org>
Cc: <linux-s390@vger.kernel.org>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Claudio Imbrenda" <imbrenda@linux.ibm.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Sven Schnelle" <svens@linux.ibm.com>,
	"Thomas Huth" <thuth@redhat.com>
Subject: Re: [PATCH v3 2/3] KVM: s390: Always allocate esca_block
Date: Mon, 02 Jun 2025 11:24:34 +0200	[thread overview]
Message-ID: <DABXT5G4XDH2.36Y0Z944ORJCQ@linux.ibm.com> (raw)
In-Reply-To: <609a3511-4dae-47b8-a6a6-45b8f3b989a8@linux.ibm.com>

On Mon May 26, 2025 at 12:36 PM CEST, Janosch Frank wrote:
> On 5/22/25 11:31 AM, Christoph Schlameuss wrote:
>> Instead of allocating a BSCA and upgrading it for PV or when adding the
>> 65th cpu we can always use the ESCA.
>> 
>> The only downside of the change is that we will always allocate 4 pages
>> for a 248 cpu ESCA instead of a single page for the BSCA per VM.
>> In return we can delete a bunch of checks and special handling depending
>> on the SCA type as well as the whole BSCA to ESCA conversion.
>> 
>> As a fallback we can still run without SCA entries when the SIGP
>> interpretation facility or ESCA are not available.
>> 
>> Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
>> ---
>>   arch/s390/include/asm/kvm_host.h |   1 -
>>   arch/s390/kvm/interrupt.c        |  71 +++++------------
>>   arch/s390/kvm/kvm-s390.c         | 161 ++++++---------------------------------
>>   arch/s390/kvm/kvm-s390.h         |   4 +-
>>   4 files changed, 45 insertions(+), 192 deletions(-)
>> 
>> diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
>> index f51bac835260f562eaf4bbfd373a24bfdbc43834..d03e354a63d9c931522c1a1607eba8685c24527f 100644
>> --- a/arch/s390/include/asm/kvm_host.h
>> +++ b/arch/s390/include/asm/kvm_host.h
>> @@ -631,7 +631,6 @@ struct kvm_s390_pv {
>>   
>
> [...]
>
>>   int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>>   {
>> -	gfp_t alloc_flags = GFP_KERNEL_ACCOUNT;
>> -	int i, rc;
>> +	gfp_t alloc_flags = GFP_KERNEL_ACCOUNT | __GFP_ZERO;
>>   	char debug_name[16];
>> -	static unsigned long sca_offset;
>> +	int i, rc;
>>   
>>   	rc = -EINVAL;
>>   #ifdef CONFIG_KVM_S390_UCONTROL
>> @@ -3358,17 +3341,12 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>>   	if (!sclp.has_64bscao)
>>   		alloc_flags |= GFP_DMA;
>>   	rwlock_init(&kvm->arch.sca_lock);
>> -	/* start with basic SCA */
>> -	kvm->arch.sca = (struct bsca_block *) get_zeroed_page(alloc_flags);
>> -	if (!kvm->arch.sca)
>> -		goto out_err;
>>   	mutex_lock(&kvm_lock);
>> -	sca_offset += 16;
>> -	if (sca_offset + sizeof(struct bsca_block) > PAGE_SIZE)
>> -		sca_offset = 0;
>> -	kvm->arch.sca = (struct bsca_block *)
>> -			((char *) kvm->arch.sca + sca_offset);
>> +
>> +	kvm->arch.sca = alloc_pages_exact(sizeof(*kvm->arch.sca), alloc_flags);
>
> kvm->arch.sca is (void *) at the point of this patch, which makes this a 
> very bad idea. Granted, you fix that up in the next patch but this is 
> still wrong.
>
> Any reason why you have patch #3 at all?
> We could just squash it and avoid this problem?
>

Yes, I can just roll that up into a single patch. Just thought it would be a bit
easier to review this way.

>>   	mutex_unlock(&kvm_lock);
>> +	if (!kvm->arch.sca)
>> +		goto out_err;
>>   
>>   	sprintf(debug_name, "kvm-%u", current->pid);
>>   
>
> [...]
>
>>   /* needs disabled preemption to protect from TOD sync and vcpu_load/put */
>> @@ -3919,7 +3808,7 @@ static int kvm_s390_vcpu_setup(struct kvm_vcpu *vcpu)
>>   		vcpu->arch.sie_block->eca |= ECA_IB;
>>   	if (sclp.has_siif)
>>   		vcpu->arch.sie_block->eca |= ECA_SII;
>> -	if (sclp.has_sigpif)
>> +	if (kvm_s390_use_sca_entries())
>>   		vcpu->arch.sie_block->eca |= ECA_SIGPI;
>>   	if (test_kvm_facility(vcpu->kvm, 129)) {
>>   		vcpu->arch.sie_block->eca |= ECA_VX;
>> diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
>> index 8d3bbb2dd8d27802bbde2a7bd1378033ad614b8e..2c8e177e4af8f2dab07fd42a904cefdea80f6855 100644
>> --- a/arch/s390/kvm/kvm-s390.h
>> +++ b/arch/s390/kvm/kvm-s390.h
>> @@ -531,7 +531,7 @@ int kvm_s390_handle_per_event(struct kvm_vcpu *vcpu);
>>   /* support for Basic/Extended SCA handling */
>>   static inline union ipte_control *kvm_s390_get_ipte_control(struct kvm *kvm)
>>   {
>> -	struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
>> +	struct esca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
>
> Remove the comment as well please
>

That's also fully removed in patch 3 along with he whole method.

>>   
>>   	return &sca->ipte_control;
>>   }
>> @@ -542,7 +542,7 @@ static inline int kvm_s390_use_sca_entries(void)
>>   	 * might use the entries. By not setting the entries and keeping them
>>   	 * invalid, hardware will not access them but intercept.
>>   	 */
>> -	return sclp.has_sigpif;
>> +	return sclp.has_sigpif && sclp.has_esca;
>>   }
>>   void kvm_s390_reinject_machine_check(struct kvm_vcpu *vcpu,
>>   				     struct mcck_volatile_info *mcck_info);
>> 


  reply	other threads:[~2025-06-02  9:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-22  9:31 [PATCH v3 0/3] KVM: s390: Use ESCA instead of BSCA at VM init Christoph Schlameuss
2025-05-22  9:31 ` [PATCH v3 1/3] KVM: s390: Set KVM_MAX_VCPUS to 256 Christoph Schlameuss
2025-05-30  7:39   ` Janosch Frank
2025-05-22  9:31 ` [PATCH v3 2/3] KVM: s390: Always allocate esca_block Christoph Schlameuss
2025-05-22 10:49   ` Claudio Imbrenda
2025-05-26  8:22   ` Janosch Frank
2025-06-02 10:01     ` Christoph Schlameuss
2025-05-26 10:36   ` Janosch Frank
2025-06-02  9:24     ` Christoph Schlameuss [this message]
2025-05-22  9:31 ` [PATCH v3 3/3] KVM: s390: Specify kvm->arch.sca as esca_block Christoph Schlameuss

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=DABXT5G4XDH2.36Y0Z944ORJCQ@linux.ibm.com \
    --to=schlameuss@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.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-s390@vger.kernel.org \
    --cc=svens@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.