From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <zenghui.yu@linux.dev>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, 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: Sun, 10 Sep 2023 19:18:37 +0100 [thread overview]
Message-ID: <87ledd51tu.wl-maz@kernel.org> (raw)
In-Reply-To: <fd96f034-b7ca-c1bd-a94e-06f8e84e52a7@linux.dev>
On Sun, 10 Sep 2023 17:25:36 +0100,
Zenghui Yu <zenghui.yu@linux.dev> wrote:
>
> 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.
Huh, well caught. That was definitely a bug that was there for ever,
and only you spotted it. Guess I should flag it as a stable candidate.
> 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 don't think there is any such rule. As far as I can tell, any number
will do as long as it is within the range [0, max_vcpu_id). Of course,
max_vcpu_id doesn't even exist on arm64. From what I can tell, this is
just some random number between 0 and 511 for us (GICv2
notwithstanding).
> 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..
Huh, this is incredibly dodgy. I had a go at a few occurrences (see
below), but this is hardly a complete list.
> Besides, the refactor itself looks good to me.
Cool, thanks!
M.
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 6dcdae4d38cb..e32c867e7b48 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -458,7 +458,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
timer_ctx->irq.level);
if (!userspace_irqchip(vcpu->kvm)) {
- ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
+ ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_idx,
timer_irq(timer_ctx),
timer_ctx->irq.level,
timer_ctx);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index a3b13281d38a..1f7b074b81df 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -439,9 +439,9 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
* We might get preempted before the vCPU actually runs, but
* over-invalidation doesn't affect correctness.
*/
- if (*last_ran != vcpu->vcpu_id) {
+ if (*last_ran != vcpu->vcpu_idx) {
kvm_call_hyp(__kvm_flush_cpu_context, mmu);
- *last_ran = vcpu->vcpu_id;
+ *last_ran = vcpu->vcpu_idx;
}
vcpu->cpu = cpu;
@@ -1207,7 +1207,7 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level,
if (vcpu_idx >= nrcpus)
return -EINVAL;
- vcpu = kvm_get_vcpu(kvm, vcpu_idx);
+ vcpu = kvm_get_vcpu_by_id(kvm, vcpu_idx);
if (!vcpu)
return -EINVAL;
@@ -1222,14 +1222,14 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level,
if (vcpu_idx >= nrcpus)
return -EINVAL;
- vcpu = kvm_get_vcpu(kvm, vcpu_idx);
+ vcpu = kvm_get_vcpu_by_id(kvm, vcpu_idx);
if (!vcpu)
return -EINVAL;
if (irq_num < VGIC_NR_SGIS || irq_num >= VGIC_NR_PRIVATE_IRQS)
return -EINVAL;
- return kvm_vgic_inject_irq(kvm, vcpu->vcpu_id, irq_num, level, NULL);
+ return kvm_vgic_inject_irq(kvm, vcpu->vcpu_idx, irq_num, level, NULL);
case KVM_ARM_IRQ_TYPE_SPI:
if (!irqchip_in_kernel(kvm))
return -ENXIO;
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index 6b066e04dc5d..4448940b6d79 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -348,7 +348,7 @@ static void kvm_pmu_update_state(struct kvm_vcpu *vcpu)
pmu->irq_level = overflow;
if (likely(irqchip_in_kernel(vcpu->kvm))) {
- int ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
+ int ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_idx,
pmu->irq_num, overflow, pmu);
WARN_ON(ret);
}
diff --git a/arch/arm64/kvm/vgic/vgic-debug.c b/arch/arm64/kvm/vgic/vgic-debug.c
index 07aa0437125a..85606a531dc3 100644
--- a/arch/arm64/kvm/vgic/vgic-debug.c
+++ b/arch/arm64/kvm/vgic/vgic-debug.c
@@ -166,7 +166,7 @@ static void print_header(struct seq_file *s, struct vgic_irq *irq,
if (vcpu) {
hdr = "VCPU";
- id = vcpu->vcpu_id;
+ id = vcpu->vcpu_idx;
}
seq_printf(s, "\n");
@@ -212,7 +212,7 @@ static void print_irq_state(struct seq_file *s, struct vgic_irq *irq,
" %2d "
"\n",
type, irq->intid,
- (irq->target_vcpu) ? irq->target_vcpu->vcpu_id : -1,
+ (irq->target_vcpu) ? irq->target_vcpu->vcpu_idx : -1,
pending,
irq->line_level,
irq->active,
@@ -224,7 +224,7 @@ static void print_irq_state(struct seq_file *s, struct vgic_irq *irq,
irq->mpidr,
irq->source,
irq->priority,
- (irq->vcpu) ? irq->vcpu->vcpu_id : -1);
+ (irq->vcpu) ? irq->vcpu->vcpu_idx : -1);
}
static int vgic_debug_show(struct seq_file *s, void *v)
diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
index 212b73a715c1..82b264ad68c4 100644
--- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
+++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
@@ -345,7 +345,7 @@ int vgic_v2_parse_attr(struct kvm_device *dev, struct kvm_device_attr *attr,
if (cpuid >= atomic_read(&dev->kvm->online_vcpus))
return -EINVAL;
- reg_attr->vcpu = kvm_get_vcpu(dev->kvm, cpuid);
+ reg_attr->vcpu = kvm_get_vcpu_by_id(dev->kvm, cpuid);
reg_attr->addr = attr->attr & KVM_DEV_ARM_VGIC_OFFSET_MASK;
return 0;
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <zenghui.yu@linux.dev>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, 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: Sun, 10 Sep 2023 19:18:37 +0100 [thread overview]
Message-ID: <87ledd51tu.wl-maz@kernel.org> (raw)
In-Reply-To: <fd96f034-b7ca-c1bd-a94e-06f8e84e52a7@linux.dev>
On Sun, 10 Sep 2023 17:25:36 +0100,
Zenghui Yu <zenghui.yu@linux.dev> wrote:
>
> 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.
Huh, well caught. That was definitely a bug that was there for ever,
and only you spotted it. Guess I should flag it as a stable candidate.
> 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 don't think there is any such rule. As far as I can tell, any number
will do as long as it is within the range [0, max_vcpu_id). Of course,
max_vcpu_id doesn't even exist on arm64. From what I can tell, this is
just some random number between 0 and 511 for us (GICv2
notwithstanding).
> 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..
Huh, this is incredibly dodgy. I had a go at a few occurrences (see
below), but this is hardly a complete list.
> Besides, the refactor itself looks good to me.
Cool, thanks!
M.
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 6dcdae4d38cb..e32c867e7b48 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -458,7 +458,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
timer_ctx->irq.level);
if (!userspace_irqchip(vcpu->kvm)) {
- ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
+ ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_idx,
timer_irq(timer_ctx),
timer_ctx->irq.level,
timer_ctx);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index a3b13281d38a..1f7b074b81df 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -439,9 +439,9 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
* We might get preempted before the vCPU actually runs, but
* over-invalidation doesn't affect correctness.
*/
- if (*last_ran != vcpu->vcpu_id) {
+ if (*last_ran != vcpu->vcpu_idx) {
kvm_call_hyp(__kvm_flush_cpu_context, mmu);
- *last_ran = vcpu->vcpu_id;
+ *last_ran = vcpu->vcpu_idx;
}
vcpu->cpu = cpu;
@@ -1207,7 +1207,7 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level,
if (vcpu_idx >= nrcpus)
return -EINVAL;
- vcpu = kvm_get_vcpu(kvm, vcpu_idx);
+ vcpu = kvm_get_vcpu_by_id(kvm, vcpu_idx);
if (!vcpu)
return -EINVAL;
@@ -1222,14 +1222,14 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level,
if (vcpu_idx >= nrcpus)
return -EINVAL;
- vcpu = kvm_get_vcpu(kvm, vcpu_idx);
+ vcpu = kvm_get_vcpu_by_id(kvm, vcpu_idx);
if (!vcpu)
return -EINVAL;
if (irq_num < VGIC_NR_SGIS || irq_num >= VGIC_NR_PRIVATE_IRQS)
return -EINVAL;
- return kvm_vgic_inject_irq(kvm, vcpu->vcpu_id, irq_num, level, NULL);
+ return kvm_vgic_inject_irq(kvm, vcpu->vcpu_idx, irq_num, level, NULL);
case KVM_ARM_IRQ_TYPE_SPI:
if (!irqchip_in_kernel(kvm))
return -ENXIO;
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index 6b066e04dc5d..4448940b6d79 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -348,7 +348,7 @@ static void kvm_pmu_update_state(struct kvm_vcpu *vcpu)
pmu->irq_level = overflow;
if (likely(irqchip_in_kernel(vcpu->kvm))) {
- int ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
+ int ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_idx,
pmu->irq_num, overflow, pmu);
WARN_ON(ret);
}
diff --git a/arch/arm64/kvm/vgic/vgic-debug.c b/arch/arm64/kvm/vgic/vgic-debug.c
index 07aa0437125a..85606a531dc3 100644
--- a/arch/arm64/kvm/vgic/vgic-debug.c
+++ b/arch/arm64/kvm/vgic/vgic-debug.c
@@ -166,7 +166,7 @@ static void print_header(struct seq_file *s, struct vgic_irq *irq,
if (vcpu) {
hdr = "VCPU";
- id = vcpu->vcpu_id;
+ id = vcpu->vcpu_idx;
}
seq_printf(s, "\n");
@@ -212,7 +212,7 @@ static void print_irq_state(struct seq_file *s, struct vgic_irq *irq,
" %2d "
"\n",
type, irq->intid,
- (irq->target_vcpu) ? irq->target_vcpu->vcpu_id : -1,
+ (irq->target_vcpu) ? irq->target_vcpu->vcpu_idx : -1,
pending,
irq->line_level,
irq->active,
@@ -224,7 +224,7 @@ static void print_irq_state(struct seq_file *s, struct vgic_irq *irq,
irq->mpidr,
irq->source,
irq->priority,
- (irq->vcpu) ? irq->vcpu->vcpu_id : -1);
+ (irq->vcpu) ? irq->vcpu->vcpu_idx : -1);
}
static int vgic_debug_show(struct seq_file *s, void *v)
diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
index 212b73a715c1..82b264ad68c4 100644
--- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
+++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
@@ -345,7 +345,7 @@ int vgic_v2_parse_attr(struct kvm_device *dev, struct kvm_device_attr *attr,
if (cpuid >= atomic_read(&dev->kvm->online_vcpus))
return -EINVAL;
- reg_attr->vcpu = kvm_get_vcpu(dev->kvm, cpuid);
+ reg_attr->vcpu = kvm_get_vcpu_by_id(dev->kvm, cpuid);
reg_attr->addr = attr->attr & KVM_DEV_ARM_VGIC_OFFSET_MASK;
return 0;
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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 18:18 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
2023-09-10 16:25 ` Zenghui Yu
2023-09-10 18:18 ` Marc Zyngier [this message]
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=87ledd51tu.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=yuzenghui@huawei.com \
--cc=zenghui.yu@linux.dev \
--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.