From: Zenghui Yu <zenghui.yu@linux.dev>
To: Marc Zyngier <maz@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org
Cc: James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
Xu Zhao <zhaoxu.35@bytedance.com>
Subject: Re: [PATCH 4/5] KVM: arm64: vgic-v3: Refactor GICv3 SGI generation
Date: Mon, 11 Sep 2023 00:25:36 +0800 [thread overview]
Message-ID: <fd96f034-b7ca-c1bd-a94e-06f8e84e52a7@linux.dev> (raw)
In-Reply-To: <20230907100931.1186690-5-maz@kernel.org>
Hi Marc,
On 2023/9/7 18:09, Marc Zyngier wrote:
> As we're about to change the way SGIs are sent, start by splitting
> out some of the basic functionnality: instead of intermingling
functionality
> the broadcast and non-broadcast cases with the actual SGI generation,
> perform the following cleanups:
>
> - move the SGI queuing into its own helper
> - split the broadcast code from the affinity-driven code
> - replace the mask/shift combinations with FIELD_GET()
>
> The result is much more readable, and paves the way for further
> optimisations.
Indeed!
> @@ -1070,19 +1102,30 @@ void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg, bool allow_group1)
> {
> struct kvm *kvm = vcpu->kvm;
> struct kvm_vcpu *c_vcpu;
> - u16 target_cpus;
> + unsigned long target_cpus;
> u64 mpidr;
> - int sgi;
> - int vcpu_id = vcpu->vcpu_id;
> - bool broadcast;
> - unsigned long c, flags;
> -
> - sgi = (reg & ICC_SGI1R_SGI_ID_MASK) >> ICC_SGI1R_SGI_ID_SHIFT;
> - broadcast = reg & BIT_ULL(ICC_SGI1R_IRQ_ROUTING_MODE_BIT);
> - target_cpus = (reg & ICC_SGI1R_TARGET_LIST_MASK) >> ICC_SGI1R_TARGET_LIST_SHIFT;
> + u32 sgi;
> + unsigned long c;
> +
> + sgi = FIELD_GET(ICC_SGI1R_SGI_ID_MASK, reg);
> +
> + /* Broadcast */
> + if (unlikely(reg & BIT_ULL(ICC_SGI1R_IRQ_ROUTING_MODE_BIT))) {
> + kvm_for_each_vcpu(c, c_vcpu, kvm) {
> + /* Don't signal the calling VCPU */
> + if (c_vcpu == vcpu)
> + continue;
> +
> + vgic_v3_queue_sgi(c_vcpu, sgi, allow_group1);
> + }
> +
> + return;
> + }
> +
> mpidr = SGI_AFFINITY_LEVEL(reg, 3);
> mpidr |= SGI_AFFINITY_LEVEL(reg, 2);
> mpidr |= SGI_AFFINITY_LEVEL(reg, 1);
> + target_cpus = FIELD_GET(ICC_SGI1R_TARGET_LIST_MASK, reg);
>
> /*
> * We iterate over all VCPUs to find the MPIDRs matching the request.
> @@ -1091,54 +1134,19 @@ void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg, bool allow_group1)
> * VCPUs when most of the times we just signal a single VCPU.
> */
> kvm_for_each_vcpu(c, c_vcpu, kvm) {
> - struct vgic_irq *irq;
> + int level0;
>
> /* Exit early if we have dealt with all requested CPUs */
> - if (!broadcast && target_cpus == 0)
> + if (target_cpus == 0)
> break;
> -
> - /* Don't signal the calling VCPU */
> - if (broadcast && c == vcpu_id)
Unrelated to this patch, but it looks that we were comparing the value
of *vcpu_idx* and vcpu_id to skip the calling VCPU. Is there a rule in
KVM that userspace should invoke KVM_CREATE_VCPU with sequential
"vcpu id"s, starting at 0, so that the user-provided vcpu_id always
equals to the KVM-internal vcpu_idx for a given VCPU?
I asked because it seems that in kvm/arm64 we always use
kvm_get_vcpu(kvm, i) to obtain the kvm_vcpu pointer, even if *i* is
sometimes essentially provided by userspace..
Besides, the refactor itself looks good to me.
Thanks,
Zenghui
WARNING: multiple messages have this Message-ID (diff)
From: Zenghui Yu <zenghui.yu@linux.dev>
To: Marc Zyngier <maz@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org
Cc: James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
Xu Zhao <zhaoxu.35@bytedance.com>
Subject: Re: [PATCH 4/5] KVM: arm64: vgic-v3: Refactor GICv3 SGI generation
Date: Mon, 11 Sep 2023 00:25:36 +0800 [thread overview]
Message-ID: <fd96f034-b7ca-c1bd-a94e-06f8e84e52a7@linux.dev> (raw)
In-Reply-To: <20230907100931.1186690-5-maz@kernel.org>
Hi Marc,
On 2023/9/7 18:09, Marc Zyngier wrote:
> As we're about to change the way SGIs are sent, start by splitting
> out some of the basic functionnality: instead of intermingling
functionality
> the broadcast and non-broadcast cases with the actual SGI generation,
> perform the following cleanups:
>
> - move the SGI queuing into its own helper
> - split the broadcast code from the affinity-driven code
> - replace the mask/shift combinations with FIELD_GET()
>
> The result is much more readable, and paves the way for further
> optimisations.
Indeed!
> @@ -1070,19 +1102,30 @@ void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg, bool allow_group1)
> {
> struct kvm *kvm = vcpu->kvm;
> struct kvm_vcpu *c_vcpu;
> - u16 target_cpus;
> + unsigned long target_cpus;
> u64 mpidr;
> - int sgi;
> - int vcpu_id = vcpu->vcpu_id;
> - bool broadcast;
> - unsigned long c, flags;
> -
> - sgi = (reg & ICC_SGI1R_SGI_ID_MASK) >> ICC_SGI1R_SGI_ID_SHIFT;
> - broadcast = reg & BIT_ULL(ICC_SGI1R_IRQ_ROUTING_MODE_BIT);
> - target_cpus = (reg & ICC_SGI1R_TARGET_LIST_MASK) >> ICC_SGI1R_TARGET_LIST_SHIFT;
> + u32 sgi;
> + unsigned long c;
> +
> + sgi = FIELD_GET(ICC_SGI1R_SGI_ID_MASK, reg);
> +
> + /* Broadcast */
> + if (unlikely(reg & BIT_ULL(ICC_SGI1R_IRQ_ROUTING_MODE_BIT))) {
> + kvm_for_each_vcpu(c, c_vcpu, kvm) {
> + /* Don't signal the calling VCPU */
> + if (c_vcpu == vcpu)
> + continue;
> +
> + vgic_v3_queue_sgi(c_vcpu, sgi, allow_group1);
> + }
> +
> + return;
> + }
> +
> mpidr = SGI_AFFINITY_LEVEL(reg, 3);
> mpidr |= SGI_AFFINITY_LEVEL(reg, 2);
> mpidr |= SGI_AFFINITY_LEVEL(reg, 1);
> + target_cpus = FIELD_GET(ICC_SGI1R_TARGET_LIST_MASK, reg);
>
> /*
> * We iterate over all VCPUs to find the MPIDRs matching the request.
> @@ -1091,54 +1134,19 @@ void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg, bool allow_group1)
> * VCPUs when most of the times we just signal a single VCPU.
> */
> kvm_for_each_vcpu(c, c_vcpu, kvm) {
> - struct vgic_irq *irq;
> + int level0;
>
> /* Exit early if we have dealt with all requested CPUs */
> - if (!broadcast && target_cpus == 0)
> + if (target_cpus == 0)
> break;
> -
> - /* Don't signal the calling VCPU */
> - if (broadcast && c == vcpu_id)
Unrelated to this patch, but it looks that we were comparing the value
of *vcpu_idx* and vcpu_id to skip the calling VCPU. Is there a rule in
KVM that userspace should invoke KVM_CREATE_VCPU with sequential
"vcpu id"s, starting at 0, so that the user-provided vcpu_id always
equals to the KVM-internal vcpu_idx for a given VCPU?
I asked because it seems that in kvm/arm64 we always use
kvm_get_vcpu(kvm, i) to obtain the kvm_vcpu pointer, even if *i* is
sometimes essentially provided by userspace..
Besides, the refactor itself looks good to me.
Thanks,
Zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-09-10 16:26 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 10:09 [PATCH 0/5] KVM: arm64: Accelerate lookup of vcpus by MPIDR values Marc Zyngier
2023-09-07 10:09 ` Marc Zyngier
2023-09-07 10:09 ` [PATCH 1/5] KVM: arm64: Simplify kvm_vcpu_get_mpidr_aff() Marc Zyngier
2023-09-07 10:09 ` Marc Zyngier
2023-09-07 15:28 ` Joey Gouly
2023-09-07 15:28 ` Joey Gouly
2023-09-07 10:09 ` [PATCH 2/5] KVM: arm64: Build MPIDR to vcpu index cache at runtime Marc Zyngier
2023-09-07 10:09 ` Marc Zyngier
2023-09-07 15:29 ` Joey Gouly
2023-09-07 15:29 ` Joey Gouly
2023-09-07 18:15 ` Marc Zyngier
2023-09-07 18:15 ` Marc Zyngier
2023-09-07 10:09 ` [PATCH 3/5] KVM: arm64: Fast-track kvm_mpidr_to_vcpu() when mpidr_data is available Marc Zyngier
2023-09-07 10:09 ` Marc Zyngier
2023-09-07 15:29 ` Joey Gouly
2023-09-07 15:29 ` Joey Gouly
2023-09-07 10:09 ` [PATCH 4/5] KVM: arm64: vgic-v3: Refactor GICv3 SGI generation Marc Zyngier
2023-09-07 10:09 ` Marc Zyngier
2023-09-10 16:25 ` Zenghui Yu [this message]
2023-09-10 16:25 ` Zenghui Yu
2023-09-10 18:18 ` Marc Zyngier
2023-09-10 18:18 ` Marc Zyngier
2023-09-11 15:57 ` Zenghui Yu
2023-09-11 15:57 ` Zenghui Yu
2023-09-12 13:07 ` Marc Zyngier
2023-09-12 13:07 ` Marc Zyngier
2023-09-07 10:09 ` [PATCH 5/5] KVM: arm64: vgic-v3: Optimize affinity-based SGI injection Marc Zyngier
2023-09-07 10:09 ` Marc Zyngier
2023-09-07 15:30 ` [PATCH 0/5] KVM: arm64: Accelerate lookup of vcpus by MPIDR values Joey Gouly
2023-09-07 15:30 ` Joey Gouly
2023-09-07 18:17 ` Marc Zyngier
2023-09-07 18:17 ` Marc Zyngier
2023-09-07 20:27 ` Joey Gouly
2023-09-07 20:27 ` Joey Gouly
2023-09-08 7:21 ` Marc Zyngier
2023-09-08 7:21 ` Marc Zyngier
2023-09-11 15:01 ` Shameerali Kolothum Thodi
2023-09-11 15:01 ` Shameerali Kolothum Thodi
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=fd96f034-b7ca-c1bd-a94e-06f8e84e52a7@linux.dev \
--to=zenghui.yu@linux.dev \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=yuzenghui@huawei.com \
--cc=zhaoxu.35@bytedance.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.