From: Bibo Mao <maobibo@loongson.cn>
To: Huacai Chen <chenhuacai@kernel.org>
Cc: kernel@xen0n.name, kvm@vger.kernel.org,
loongarch@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/6] LoongArch: KVM: Set max VM supported FPU type with FPU exception
Date: Thu, 9 Apr 2026 20:11:12 +0800 [thread overview]
Message-ID: <74e8fa9e-90f6-175e-fb98-2e4504d5f15d@loongson.cn> (raw)
In-Reply-To: <CAAhV-H4+A0bs07v4B8BTCqbNsG5SLSjjx8sh5Lz23i+R37RAKw@mail.gmail.com>
On 2026/4/8 下午3:47, Huacai Chen wrote:
> On Wed, Apr 8, 2026 at 9:04 AM Bibo Mao <maobibo@loongson.cn> wrote:
>>
>>
>>
>> On 2026/4/7 下午8:41, Huacai Chen wrote:
>>> On Mon, Mar 30, 2026 at 6:00 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>
>>>> Hi, Bibo,
>>>>
>>>>
>>>> On Mon, Mar 30, 2026 at 11:58 AM Bibo Mao <maobibo@loongson.cn> wrote:
>>>>>
>>>>> With FPU save and restore flow, the cost is the same with different
>>>>> FPU width 8/16/32 bytes, whatever from CPU cycle and cache line impaction.
>>>>>
>>>>> Here is to enable FPU with max VM supported type, for example if
>>>>> VM supports LASX instrction, enable FPU with LASX type even with FPU
>>>>> exeception. So it can avoid possible LSX/LASX exception in future.
>>>>>
>>>>> With context switch microbench which may touch FPU and LASX, there is 9%
>>>>> improvement when halt_poll_ns is disabled. The command is
>>>>> "./context --test=pipe" and source code located at:
>>>>> https://github.com/bibo-mao/context_switch/blob/main/context.c
>>>>>
>>>>> Original Wih patch improvement
>>>>> 75232 82440 9%
>>>>>
>>>>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>>>>> ---
>>>>> v1 ... v2:
>>>>> 1. Enable FPU with max VM supported FPU type, rather than max used type.
>>>>> 2. Add new request bit KVM_REQ_LBT_LOAD for LBT restore
>>>>> 3. Rename KVM_REQ_AUX_LOAD with KVM_REQ_FPU_LOAD
>>>>> 3. Remove aux_ldtype and KVM_LARCH_LSX/KVM_LARCH_LSX
>>>>> 4. Remove middle FPU state handling in kvm_own_lsx() and kvm_own_lasx(),
>>>>> directly enable LSX or LASX from FPU none state.
>>>>> ---
>>>>> Bibo Mao (6):
>>>>> LoongArch: KVM: Add separate KVM_REQ_LBT_LOAD request bit
>>>>> LoongArch: KVM: Enable FPU with max VM supported FPU type
>>>>> LoongArch: KVM: Rename KVM_REQ_AUX_LOAD with KVM_REQ_FPU_LOAD
>>>> Patch-1 add KVM_REQ_LBT_LOAD, then KVM_REQ_AUX_LOAD is only for FPU,
>>>> so I think Patch-3 should be squashed into Patch-1.
>>>>
>>>>> LoongArch: KVM: Remove some middle FPU states
>>>>> LoongArch: KVM: Use vm_guest_has_fpu API in kvm_lose_fpu()
>>>>> LoongArch: KVM: Remove KVM_LARCH_LASX and KVM_LARCH_LSX
>>>> Patch-5 remove the consumer side of KVM_LARCH_LASX / KVM_LARCH_LSX and
>>>> Patch-6 remove the provider side of KVM_LARCH_LASX / KVM_LARCH_LSX, so
>>>> I think Patch-6 should be squashed into Patch-5, too.
>>> And could you please test the power consumption where there are many
>>> VMs that only use FPU rather than LSX/LASX? As far as I know, the
>> Hi Huacai,
>>
>> Thanks for reviewing this patch
>> Could you help me to test the power consumption with this patch?
>>> power consumption of LASX is significantly more than FPU, which is a
>> Could the describe the detail scenery wheree LASX instruction is
>> frequently used by application or LASX EUEN enabled?
> The purpose is to evaluate power consumption before and after this series.
>
> So we can run 10 VMs (suppose there are 4 cores), and there is a
> workload run in every VM, the workload only uses FPU, no LSX and LASX.
> Before this series, KVM only save/restore FPU context; after this
> series, KVM will save/restore LASX context.
In theory there should be such test, only that it requires special Power
Management team and testbed. Even if there is such team, maybe they care
power consumption about DDR and screen, do not want do such experiments
for this patch.
If someone is volunteer to do this, I do not object, also I want to get
the result. Just from my guess, there should be no much difference since
FPU context switch is much smaller than the whole workload, else the
workload is just FPU context switch.
Regards
Bibo Mao
>
> If the power consumptions are similar, then this series is perfect.
>
> Huacai
>
>>
>> Regards
>> Bibo Mao
>>> little similar to AVX512 (Linus said it is a power virus).
>>>
>>> Huacai
>>>
>>>>
>>>>
>>>> Huacai
>>>>
>>>>>
>>>>> arch/loongarch/include/asm/kvm_host.h | 6 +--
>>>>> arch/loongarch/kvm/exit.c | 21 +++-----
>>>>> arch/loongarch/kvm/vcpu.c | 78 ++++++++-------------------
>>>>> 3 files changed, 30 insertions(+), 75 deletions(-)
>>>>>
>>>>>
>>>>> base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
>>>>> --
>>>>> 2.39.3
>>>>>
>>>>>
>>
>>
next prev parent reply other threads:[~2026-04-09 12:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 3:58 [PATCH v2 0/6] LoongArch: KVM: Set max VM supported FPU type with FPU exception Bibo Mao
2026-03-30 3:58 ` [PATCH v2 1/6] LoongArch: KVM: Add separate KVM_REQ_LBT_LOAD request bit Bibo Mao
2026-03-30 3:58 ` [PATCH v2 2/6] LoongArch: KVM: Enable FPU with max VM supported FPU type Bibo Mao
2026-03-30 3:58 ` [PATCH v2 3/6] LoongArch: KVM: Rename KVM_REQ_AUX_LOAD with KVM_REQ_FPU_LOAD Bibo Mao
2026-03-30 3:58 ` [PATCH v2 4/6] LoongArch: KVM: Remove some middle FPU states Bibo Mao
2026-03-30 3:58 ` [PATCH v2 5/6] LoongArch: KVM: Use vm_guest_has_fpu API in kvm_lose_fpu() Bibo Mao
2026-03-30 3:58 ` [PATCH v2 6/6] LoongArch: KVM: Remove KVM_LARCH_LASX and KVM_LARCH_LSX Bibo Mao
2026-03-30 10:00 ` [PATCH v2 0/6] LoongArch: KVM: Set max VM supported FPU type with FPU exception Huacai Chen
2026-04-07 12:41 ` Huacai Chen
2026-04-08 1:01 ` Bibo Mao
2026-04-08 1:14 ` Xi Ruoyao
2026-04-08 7:47 ` Huacai Chen
2026-04-09 12:11 ` Bibo Mao [this message]
2026-06-01 13:52 ` Huacai Chen
2026-06-02 1:20 ` Bibo Mao
2026-06-02 4:38 ` Huacai Chen
2026-06-02 4:45 ` Bibo Mao
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=74e8fa9e-90f6-175e-fb98-2e4504d5f15d@loongson.cn \
--to=maobibo@loongson.cn \
--cc=chenhuacai@kernel.org \
--cc=kernel@xen0n.name \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).