From: WANG Xuerui <kernel@xen0n.name>
To: maobibo <maobibo@loongson.cn>,
Tianrui Zhao <zhaotianrui@loongson.cn>,
Juergen Gross <jgross@suse.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>
Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
virtualization@lists.linux.dev, kvm@vger.kernel.org
Subject: Re: [PATCH v6 7/7] Documentation: KVM: Add hypercall for LoongArch
Date: Wed, 6 Mar 2024 17:22:43 +0800 [thread overview]
Message-ID: <4039d1ff-8e9f-42cf-a8fa-b326102fcbf5@xen0n.name> (raw)
In-Reply-To: <7079bf3b-a7af-7cab-be78-3de1081649e1@loongson.cn>
On 3/6/24 11:28, maobibo wrote:
> On 2024/3/6 上午2:26, WANG Xuerui wrote:
>> On 3/4/24 17:10, maobibo wrote:
>>> On 2024/3/2 下午5:41, WANG Xuerui wrote:
>>>> On 3/2/24 16:47, Bibo Mao wrote:
>>>>> [snip]
>>>>> +
>>>>> +KVM hypercall ABI
>>>>> +=================
>>>>> +
>>>>> +Hypercall ABI on KVM is simple, only one scratch register a0 (v0)
>>>>> and at most
>>>>> +five generic registers used as input parameter. FP register and
>>>>> vector register
>>>>> +is not used for input register and should not be modified during
>>>>> hypercall.
>>>>> +Hypercall function can be inlined since there is only one scratch
>>>>> register.
>>>>
>>>> It should be pointed out explicitly that on hypercall return all
>>> Well, return value description will added. What do think about the
>>> meaning of return value for KVM_HCALL_FUNC_PV_IPI hypercall? The
>>> number of CPUs with IPI delivered successfully like kvm x86 or simply
>>> success/failure?
I just noticed I've forgotten to comment on this question. FYI, RISC-V
SBI's equivalent [1] doesn't even indicate errors. And from my
perspective, we can always add a new hypercall returning more info
should that info is needed in the future; for now I don't have a problem
whether the return type is void, bool or number of CPUs that are
successfully reached.
[1]:
https://github.com/riscv-non-isa/riscv-sbi-doc/blob/v2.0/src/ext-ipi.adoc
>>>> architectural state except ``$a0`` is preserved. Or is the whole
>>>> ``$a0 - $t8`` range clobbered, just like with Linux syscalls?
>>>>
>>> what is advantage with $a0 - > $t8 clobbered?
>>
>> Because then a hypercall is going to behave identical as an ordinary C
>> function call, which is easy for people and compilers to understand.
>>
> If you really understand detailed behavior about hypercall/syscall, the
> conclusion may be different.
>
> If T0 - T8 is clobbered with hypercall instruction, hypercall caller
> need save clobbered register, now hypercall exception save/restore all
> the registers during VM exits. If so, hypercall caller need not save
> general registers and it is not necessary scratched for hypercall ABI.
>
> Until now all the discussion the macro level, no detail code level.
>
> Can you show me some example code where T0-T8 need not save/restore
> during LoongArch hypercall exception?
I was emphasizing that consistency is generally good, and yes that's
"macroscopic" level talk. Of course, the hypercall client code would
have to do *less* work if *more* registers than the minimum are
preserved -- if right now everything is already preserved, nothing needs
to change.
But please also notice that the context switch cost is paid for every
hypercall, and we can't reduce the number of preserved registers without
breaking compatibility. So I think we can keep the current
implementation behavior, but promise less in the spec: this way we'll
keep the possibility of reducing the context switch overhead.
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
prev parent reply other threads:[~2024-03-06 9:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-02 8:25 [PATCH v6 0/7] LoongArch: Add pv ipi support on LoongArch VM Bibo Mao
2024-03-02 8:25 ` [PATCH v6 1/7] LoongArch/smp: Refine some ipi functions on LoongArch platform Bibo Mao
2024-03-02 8:25 ` [PATCH v6 2/7] LoongArch: KVM: Add hypercall instruction emulation support Bibo Mao
2024-03-02 8:25 ` [PATCH v6 3/7] LoongArch: KVM: Add cpucfg area for kvm hypervisor Bibo Mao
2024-03-02 8:25 ` [PATCH v6 4/7] LoongArch: KVM: Add vcpu search support from physical cpuid Bibo Mao
2024-03-02 8:25 ` [PATCH v6 5/7] LoongArch: KVM: Add pv ipi support on kvm side Bibo Mao
2024-03-02 8:25 ` [PATCH v6 6/7] LoongArch: Add pv ipi support on guest kernel side Bibo Mao
2024-03-02 8:47 ` [PATCH v6 7/7] Documentation: KVM: Add hypercall for LoongArch Bibo Mao
2024-03-02 9:41 ` WANG Xuerui
2024-03-04 9:10 ` maobibo
2024-03-05 18:26 ` WANG Xuerui
2024-03-06 3:28 ` maobibo
2024-03-06 9:22 ` WANG Xuerui [this message]
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=4039d1ff-8e9f-42cf-a8fa-b326102fcbf5@xen0n.name \
--to=kernel@xen0n.name \
--cc=corbet@lwn.net \
--cc=jgross@suse.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=maobibo@loongson.cn \
--cc=pbonzini@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=zhaotianrui@loongson.cn \
/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).