From: "Christoph Schlameuss" <schlameuss@linux.ibm.com>
To: "Janosch Frank" <frankja@linux.ibm.com>, <kvm@vger.kernel.org>
Cc: "Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Claudio Imbrenda" <imbrenda@linux.ibm.com>,
"Nico Boehr" <nrb@linux.ibm.com>,
"David Hildenbrand" <david@redhat.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
<linux-s390@vger.kernel.org>
Subject: Re: [PATCH RFC 3/5] KVM: s390: Shadow VSIE SCA in guest-1
Date: Wed, 19 Mar 2025 15:41:17 +0100 [thread overview]
Message-ID: <D8KBKS9B7SHE.3AL1L7RDLM0IP@linux.ibm.com> (raw)
In-Reply-To: <47c6f4b7-b8a6-4b20-b915-1c4c2d9e7c74@linux.ibm.com>
On Wed Mar 19, 2025 at 2:41 PM CET, Janosch Frank wrote:
> On 3/18/25 7:59 PM, Christoph Schlameuss wrote:
>> Introduce a new shadow_sca function into kvm_s390_handle_vsie.
>> kvm_s390_handle_vsie is called within guest-1 when guest-2 initiates the
>> VSIE.
>>
>> shadow_sca and unshadow_sca create and manage ssca_block structs in
>> guest-1 memory. References to the created ssca_blocks are kept within an
>> array and limited to the number of cpus. This ensures each VSIE in
>> execution can have its own SCA. Having the amount of shadowed SCAs
>> configurable above this is left to another patch.
>>
>> SCAOL/H in the VSIE control block are overwritten with references to the
>> shadow SCA. The original SCA pointer is saved in the vsie_page and
>> restored on VSIE exit. This limits the amount of change in the
>> preexisting VSIE pin and shadow functions.
>>
>> The shadow SCA contains the addresses of the original guest-3 SCA as
>> well as the original VSIE control blocks. With these addresses the
>> machine can directly monitor the intervention bits within the original
>> SCA entries.
>>
>> The ssca_blocks are also kept within a radix tree to reuse already
>> existing ssca_blocks efficiently. While the radix tree and array with
>> references to the ssca_blocks are held in kvm_s390_vsie.
>> The use of the ssca_blocks is tracked using an ref_count on the block
>> itself.
>>
>> No strict mapping between the guest-1 vcpu and guest-3 vcpu is enforced.
>> Instead each VSIE entry updates the shadow SCA creating a valid mapping
>> for all cpus currently in VSIE.
>>
>> Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
>> ---
>> arch/s390/include/asm/kvm_host.h | 22 +++-
>> arch/s390/kvm/vsie.c | 264 ++++++++++++++++++++++++++++++++++++++-
>> 2 files changed, 281 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
>> index 0aca5fa01f3d772c3b3dd62a22134c0d4cb9dc22..4ab196caa9e79e4c4d295d23fed65e1a142e6ab1 100644
>> --- a/arch/s390/include/asm/kvm_host.h
>> +++ b/arch/s390/include/asm/kvm_host.h
>> @@ -29,6 +29,7 @@
>> #define KVM_S390_BSCA_CPU_SLOTS 64
>> #define KVM_S390_ESCA_CPU_SLOTS 248
>> #define KVM_MAX_VCPUS 255
>> +#define KVM_S390_MAX_VCPUS 256
>
> #define KVM_S390_SSCA_CPU_SLOTS 256
>
> Yes, I'm aware, that ESCA and MAX_VCPUS are pretty confusing.
> I'm searching for solutions but they might take a while.
>
>>
>> #define KVM_INTERNAL_MEM_SLOTS 1
>>
>> @@ -137,13 +138,23 @@ struct esca_block {
>>
>> /*
>> * The shadow sca / ssca needs to cover both bsca and esca depending on what the
>> - * guest uses so we use KVM_S390_ESCA_CPU_SLOTS.
>> + * guest uses so we allocate space for 256 entries that are defined in the
>> + * architecture.
>> * The header part of the struct must not cross page boundaries.
>> */
>> struct ssca_block {
>> __u64 osca;
>> __u64 reserved08[7];
>> - struct ssca_entry cpu[KVM_S390_ESCA_CPU_SLOTS];
>> + struct ssca_entry cpu[KVM_S390_MAX_VCPUS];
>
> This should have been resolved in the previous patch, no?
>
Oops, yes, exactly.
>> +};
>> +
>> +/*
>> + * Store the vsie ssca block and accompanied management data.
>> + */
>> +struct ssca_vsie {
>> + struct ssca_block ssca; /* 0x0000 */
>> + __u8 reserved[0x2200 - 0x2040]; /* 0x2040 */
>> + atomic_t ref_count; /* 0x2200 */
>> };
>>
>
> [...]
>
>> void kvm_s390_vsie_gmap_notifier(struct gmap *gmap, unsigned long start,
>> unsigned long end)
>> {
>> @@ -699,6 +932,9 @@ static void unpin_blocks(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>>
>> hpa = (u64) scb_s->scaoh << 32 | scb_s->scaol;
>> if (hpa) {
>> + /* with vsie_sigpif scaoh/l was pointing to g1 ssca_block but
>> + * should have been reset in unshadow_sca()
>> + */
>
> There shouldn't be text in the first or last line of multi-line comments.
>
Will fix. Thx. (checkpatch seems to be fine with this, so I assume just in not
desired?)
>> unpin_guest_page(vcpu->kvm, vsie_page->sca_gpa, hpa);
>> vsie_page->sca_gpa = 0;
>> scb_s->scaol = 0;
>> @@ -775,6 +1011,9 @@ static int pin_blocks(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>> if (rc)
>> goto unpin;
>> vsie_page->sca_gpa = gpa;
>> + /* with vsie_sigpif scaoh and scaol will be overwritten
>> + * in shadow_sca to point to g1 ssca_block instead
>> + */
>
> Same
>
>> scb_s->scaoh = (u32)((u64)hpa >> 32);
>> scb_s->scaol = (u32)(u64)hpa;
>> }
>> @@ -1490,12 +1729,17 @@ int kvm_s390_handle_vsie(struct kvm_vcpu *vcpu)
>> goto out_unpin_scb;
>> rc = pin_blocks(vcpu, vsie_page);
>> if (rc)
>> - goto out_unshadow;
>> + goto out_unshadow_scb;
>> + rc = shadow_sca(vcpu, vsie_page);
>> + if (rc)
>> + goto out_unpin_blocks;
>> register_shadow_scb(vcpu, vsie_page);
>> rc = vsie_run(vcpu, vsie_page);
>> unregister_shadow_scb(vcpu);
>
> For personal preference I'd like to have a \n here to visually separate
> the cleanup from the rest of the code.
>
Sure. Will insert that.
>> + unshadow_sca(vcpu, vsie_page);
>> +out_unpin_blocks:
>> unpin_blocks(vcpu, vsie_page);
>> -out_unshadow:
>> +out_unshadow_scb:
>> unshadow_scb(vcpu, vsie_page);
>> out_unpin_scb:
>> unpin_scb(vcpu, vsie_page, scb_addr);
>> @@ -1510,12 +1754,15 @@ void kvm_s390_vsie_init(struct kvm *kvm)
>> {
>> mutex_init(&kvm->arch.vsie.mutex);
>> INIT_RADIX_TREE(&kvm->arch.vsie.addr_to_page, GFP_KERNEL_ACCOUNT);
>> + init_rwsem(&kvm->arch.vsie.ssca_lock);
>> + INIT_RADIX_TREE(&kvm->arch.vsie.osca_to_ssca, GFP_KERNEL_ACCOUNT);
>> }
>>
>> /* Destroy the vsie data structures. To be called when a vm is destroyed. */
>> void kvm_s390_vsie_destroy(struct kvm *kvm)
>> {
>> struct vsie_page *vsie_page;
>> + struct ssca_vsie *ssca;
>> int i;
>>
>> mutex_lock(&kvm->arch.vsie.mutex);
>> @@ -1531,6 +1778,17 @@ void kvm_s390_vsie_destroy(struct kvm *kvm)
>> }
>> kvm->arch.vsie.page_count = 0;
>> mutex_unlock(&kvm->arch.vsie.mutex);
>> +
>> + down_write(&kvm->arch.vsie.ssca_lock);
>> + for (i = 0; i < kvm->arch.vsie.ssca_count; i++) {
>> + ssca = kvm->arch.vsie.sscas[i];
>> + kvm->arch.vsie.sscas[i] = NULL;
>> + radix_tree_delete(&kvm->arch.vsie.osca_to_ssca,
>> + (u64)phys_to_virt(ssca->ssca.osca));
>> + free_pages((unsigned long)ssca, SSCA_PAGEORDER);
>> + }
>> + kvm->arch.vsie.ssca_count = 0;
>> + up_write(&kvm->arch.vsie.ssca_lock);
>> }
>>
>> void kvm_s390_vsie_kick(struct kvm_vcpu *vcpu)
>>
next prev parent reply other threads:[~2025-03-19 14:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 18:59 [PATCH RFC 0/5] KVM: s390: Add VSIE Interpretation Extension Facility (vsie_sigpif) Christoph Schlameuss
2025-03-18 18:59 ` [PATCH RFC 1/5] KVM: s390: Add vsie_sigpif detection Christoph Schlameuss
2025-03-18 22:26 ` David Hildenbrand
2025-03-18 18:59 ` [PATCH RFC 2/5] KVM: s390: Add ssca_block and ssca_entry structs for vsie_ie Christoph Schlameuss
2025-03-18 18:59 ` [PATCH RFC 3/5] KVM: s390: Shadow VSIE SCA in guest-1 Christoph Schlameuss
2025-03-19 13:41 ` Janosch Frank
2025-03-19 14:41 ` Christoph Schlameuss [this message]
2025-03-19 16:02 ` Janosch Frank
2025-03-20 15:22 ` Nico Boehr
2025-03-20 17:46 ` Christoph Schlameuss
2025-03-18 18:59 ` [PATCH RFC 4/5] KVM: s390: Re-init SSCA on switch to ESCA Christoph Schlameuss
2025-03-18 18:59 ` [PATCH RFC 5/5] KVM: s390: Add VSIE shadow stat counters 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=D8KBKS9B7SHE.3AL1L7RDLM0IP@linux.ibm.com \
--to=schlameuss@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=svens@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 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.