linux-kernel - Re: [RFC] KVM: arm/arm64: optimize vSGI injection performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b3e716ee-988a-49cd-996d-a27517aa8e91@bytedance.com>
Date:   Tue, 22 Aug 2023 11:51:30 +0800
From:   zhaoxu <zhaoxu.35@...edance.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     pbonzini@...hat.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, zhouyibo@...edance.com,
        zhouliang.001@...edance.com, Oliver Upton <oliver.upton@...ux.dev>,
        kvmarm@...ts.linux.dev, Mark Rutland <mark.rutland@....com>
Subject: Re: [RFC] KVM: arm/arm64: optimize vSGI injection performance

hi marc, thanks for reviewing.

On 2023/8/21 18:16, Marc Zyngier wrote:
>>> This work is based on v5.4, and here is test data:
> 
> This is a 4 year old kernel. I'm afraid you'll have to provide
> something that is relevant to a current (e.i. v6.5) kernel.
> 
In fact, the core vCPU search algorithm remains the same in the latest 
kernel: iterate all vCPUs, if mpidr matches, inject. next version will 
based on latest kernel.

>>> Based on the test results, the performance of vm  with less than 16 cores remains almost the same,
>>> while significant improvement can be observed with more than 16
>>> cores.
> 
> This triggers multiple questions:
> 
> - what is the test being used? on what hardware? how can I reproduce
>    this data?
> 
1. I utilized the ipi_benchmark 
(https://patchwork.kernel.org/project/linux-arm-kernel/patch/20171211141600.24401-1-ynorov@caviumnetworks.com/) 
with a modification to the Normal IPI target in the following manner: 
smp_call_function_single(31, handle_ipi, &time, 1).
2. On kunpeng 920 platform.
3. Using ipi_benchmark but change the target cpu in Normal IPI case, and 
use bcc or bpftrace to measuret the execution time of vgic_v3_dispatch_sgi.
> - which current guest OS *currently* make use of broadcast or 1:N
>    SGIs? Linux doesn't and overall SGI multicasting is pretty useless
>    to an OS.
> 
> [...]
Yes, arm64 linux almost never send broadcast ipi. I will use another 
test data to prove performence improvement
> 
>>>   /*
>>> - * Compare a given affinity (level 1-3 and a level 0 mask, from the SGI
>>> - * generation register ICC_SGI1R_EL1) with a given VCPU.
>>> - * If the VCPU's MPIDR matches, return the level0 affinity, otherwise
>>> - * return -1.
>>> + * Get affinity routing index from ICC_SGI_* register
>>> + * format:
>>> + *     aff3       aff2       aff1            aff0
>>> + * |- 8 bits -|- 8 bits -|- 8 bits -|- 4 bits or 8bits -|
> 
> OK, so you are implementing RSS support:
> 
> - Why isn't that mentioned anywhere in the commit log?
> 
> - Given that KVM actively limits the MPIDR to 4 bits at Aff0, how does
>    it even work the first place?
> 
> - How is that advertised to the guest?
> 
> - How can the guest enable RSS support?
> 
thanks to mention that, I also checked the relevant code, guest can't 
enable RSS, it was my oversight. This part has removed in next version.
> This is not following the GICv3 architecture, and I'm sceptical that
> it actually works as is (I strongly suspect that you have additional
> patches...).
there are nothing left, all the patchs are here
> 
> 	M.
> 
With regards
Xu