Message ID | 20240302084724.1415344-1-maobibo@loongson.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-89383-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:fa17:b0:10a:f01:a869 with SMTP id ju23csp379899dyc; Sat, 2 Mar 2024 00:47:59 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCU5NOoLHWsGEUpdYaGh5TqRgn5gY3pMPjQyQzKR1MQbkyy98rqQdx0Y4EBaY4be6SARhtQ/gS5+yKdKnqopTtGvR+tWpA== X-Google-Smtp-Source: AGHT+IHD0GDBwOtkRMgESHPv37wYAMLZ3jCRB8KH0nE+O3jdsqzNOHCtAeV4gG69fg5TTmx6O7iY X-Received: by 2002:a17:903:2a86:b0:1dc:cc64:b3e0 with SMTP id lv6-20020a1709032a8600b001dccc64b3e0mr4240410plb.69.1709369279092; Sat, 02 Mar 2024 00:47:59 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709369279; cv=pass; d=google.com; s=arc-20160816; b=ibTJCpEH0zdJsemVb5hfePdq0quVuTuUuyVpQmBDg0fHYBXC3owQEArHwX+VY/MzgR 2mG2jsSoeUtTIjUf6DIa74KBLTj7l4/3Zuqagu++tx/kNFfbFd+7o3qRyi9DQRj8OluN UiutSsUWjVldFIwKAjLc6wI3yvmGxJdoPLdtJI/X2G6KLXKiJHX1H8u91VF8ivnocTw4 NsZfxMdNnp4sZlhYHlG2y67y287WRMeKrOyRcgkg7VJ46i1ky3H/8jKUz5Lzig/h+HIn vBb4D+mqWV9jSOeSqwUjmyj4ASl56/Lonvl0rFA0e/4mPEyA6Ror9Lqttywqp0odQVlx iUbA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from; bh=AJC0L8IhLxDHhgFUU3TzZRAQaE0gxVdUIzS8iiHQCDE=; fh=3h4qnqyng34izqxXaZ0TAiy2w9FmemtzGeEAH1dZnPY=; b=Pvp0oBQuFWxFgVrIeACwobVsl0QtxS9qzAaScibIiJypv4Jh7FQRgUwvbKm4WmEtAE hcm/+/TqVWeXaTOoHddydsvCypoH2Yq+c+uRdeQ81PRR3FbY1XCJn9CXpp5p+b4fqHTa vUTyQJQwfiAhHIo2i22X8fpwMCVfDqlwPmh71tdEFAXv6eq9DutRz2pcYXVqzgtd3Ln9 2TZjBA/QxD6vRRUbjTtkf8vFxD9APoAm9vShi/Mgfddn5ch6eIlIVKTZ7jH/iIR22XoQ u3HpW7eo7MH1gTAzFTrIZlayh8+lENB6olcIZg7VC4bbK/x0GVmhfAiP4qYVv2FQ2Hc0 R2EQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=loongson.cn); spf=pass (google.com: domain of linux-kernel+bounces-89383-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-89383-ouuuleilei=gmail.com@vger.kernel.org" Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id o9-20020a170902d4c900b001db719a840csi5256637plg.569.2024.03.02.00.47.58 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Mar 2024 00:47:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-89383-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=loongson.cn); spf=pass (google.com: domain of linux-kernel+bounces-89383-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-89383-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id CA1E92854B6 for <ouuuleilei@gmail.com>; Sat, 2 Mar 2024 08:47:58 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A31A814A96; Sat, 2 Mar 2024 08:47:40 +0000 (UTC) Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8B0AE79F0; Sat, 2 Mar 2024 08:47:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709369259; cv=none; b=ZwJawgAXZjfQGxvhmzHq9NswWykXZFYheB4v94+Vsoaga0DlUpDATI8ayta9Jiqc4Q1cpjcgP4srb5xSSfia5j1dKmYbkS6djdwhs63Wt3/2W5phx3DoWR1dLu0nxUgv40Wu6rjiK4fJ7v/VG5lNfsCSVzwJXZoAp8WiKUqjhp0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709369259; c=relaxed/simple; bh=f1Y+/ht0z9E9BsX+uCJhSCI5UEi794liFywZ4dOZfI8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=iZCTbURCg46shpFlZasJlFlu5JLTYxClxNiuiM0tPPRGtz/N/86tt8B5Lt5KF1m0xYUi4+0vLD4JwUWp7erPD+xB772aG0GE05kOtWNZs9qpstiebGlLLIA7ZhD7/+az1qGzhIfQOFpxa0iUSEuogv33t6gd6Q/xAv62VFm430I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn; spf=pass smtp.mailfrom=loongson.cn; arc=none smtp.client-ip=114.242.206.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [10.2.5.213]) by gateway (Coremail) with SMTP id _____8CxSPCf5+JlLYsTAA--.50243S3; Sat, 02 Mar 2024 16:47:27 +0800 (CST) Received: from localhost.localdomain (unknown [10.2.5.213]) by localhost.localdomain (Coremail) with SMTP id AQAAf8DxfROd5+JlmFtMAA--.39607S2; Sat, 02 Mar 2024 16:47:25 +0800 (CST) From: Bibo Mao <maobibo@loongson.cn> To: 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: [PATCH v6 7/7] Documentation: KVM: Add hypercall for LoongArch Date: Sat, 2 Mar 2024 16:47:24 +0800 Message-Id: <20240302084724.1415344-1-maobibo@loongson.cn> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20240302082532.1415200-1-maobibo@loongson.cn> References: <20240302082532.1415200-1-maobibo@loongson.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf8DxfROd5+JlmFtMAA--.39607S2 X-CM-SenderInfo: xpdruxter6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoWxAFWUtr15Xr4UWw17tFy3WrX_yoWrCr1DpF 95G34fKrn7Jry7A34xJr1UWryjkr97JF47J3W8Jr10qr1DJr1fJr4UtFZ0y3W8G3y8AFW8 XF18tr1jkr1UAwcCm3ZEXasCq-sJn29KB7ZKAUJUUUU7529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUU9ab4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07 AIYIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU AVWUtwAv7VC2z280aVAFwI0_Cr0_Gr1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x 0EwIxGrwCY1x0262kKe7AKxVWUAVWUtwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMI IF0xvEx4A2jsIE14v26F4j6r4UJwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsG vfC2KfnxnUUI43ZEXa7IU8siSPUUUUU== X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792403601417960657 X-GMAIL-MSGID: 1792403601417960657 |
Series |
LoongArch: Add pv ipi support on LoongArch VM
|
|
Commit Message
maobibo
March 2, 2024, 8:47 a.m. UTC
Add documentation topic for using pv_virt when running as a guest
on KVM hypervisor.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
---
Documentation/virt/kvm/index.rst | 1 +
.../virt/kvm/loongarch/hypercalls.rst | 79 +++++++++++++++++++
Documentation/virt/kvm/loongarch/index.rst | 10 +++
3 files changed, 90 insertions(+)
create mode 100644 Documentation/virt/kvm/loongarch/hypercalls.rst
create mode 100644 Documentation/virt/kvm/loongarch/index.rst
Comments
On 3/2/24 16:47, Bibo Mao wrote: > Add documentation topic for using pv_virt when running as a guest > on KVM hypervisor. > > Signed-off-by: Bibo Mao <maobibo@loongson.cn> > --- > Documentation/virt/kvm/index.rst | 1 + > .../virt/kvm/loongarch/hypercalls.rst | 79 +++++++++++++++++++ > Documentation/virt/kvm/loongarch/index.rst | 10 +++ > 3 files changed, 90 insertions(+) > create mode 100644 Documentation/virt/kvm/loongarch/hypercalls.rst > create mode 100644 Documentation/virt/kvm/loongarch/index.rst > > diff --git a/Documentation/virt/kvm/index.rst b/Documentation/virt/kvm/index.rst > index ad13ec55ddfe..9ca5a45c2140 100644 > --- a/Documentation/virt/kvm/index.rst > +++ b/Documentation/virt/kvm/index.rst > @@ -14,6 +14,7 @@ KVM > s390/index > ppc-pv > x86/index > + loongarch/index > > locking > vcpu-requests > diff --git a/Documentation/virt/kvm/loongarch/hypercalls.rst b/Documentation/virt/kvm/loongarch/hypercalls.rst > new file mode 100644 > index 000000000000..1679e48d67d2 > --- /dev/null > +++ b/Documentation/virt/kvm/loongarch/hypercalls.rst > @@ -0,0 +1,79 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +=================================== > +The LoongArch paravirtual interface > +=================================== > + > +KVM hypercalls use the HVCL instruction with code 0x100, and the hypercall > +number is put in a0 and up to five arguments may be placed in a1-a5, the > +return value is placed in v0 (alias with a0). Just say a0: the name v0 is long deprecated (has been the case ever since LoongArch got mainlined). > + > +The code for that interface can be found in arch/loongarch/kvm/* > + > +Querying for existence > +====================== > + > +To find out if we're running on KVM or not, cpucfg can be used with index > +CPUCFG_KVM_BASE (0x40000000), cpucfg range between 0x40000000 - 0x400000FF > +is marked as a specially reserved range. All existing and future processors > +will not implement any features in this range. > + > +When Linux is running on KVM, cpucfg with index CPUCFG_KVM_BASE (0x40000000) > +returns magic string "KVM\0" > + > +Once you determined you're running under a PV capable KVM, you can now use > +hypercalls as described below. So this is still the approach similar to the x86 CPUID-based implementation. But here the non-privileged behavior isn't specified -- I see there is PLV checking in Patch 3 but it's safer to have the requirement spelled out here too. But I still think this approach touches more places than strictly needed. As it is currently the case in arch/loongarch/kernel/cpu-probe.c, the FEATURES IOCSR is checked for a bit IOCSRF_VM that already signifies presence of a hypervisor; if this information can be interpreted as availability of the HVCL instruction (which I suppose is the case -- a hypervisor can always trap-and-emulate in case HVCL isn't provided by hardware), here we can already start making calls with HVCL. We can and should define a uniform interface for probing the hypervisor kind, similar to the centrally-managed RISC-V SBI implementation ID registry [1]: otherwise future non-KVM hypervisors would have to 1. somehow pretend they are KVM and eventually fail to do so, leading to subtle incompatibilities, 2. invent another way of probing for their existence, 3. piggy-back on the current KVM definition, which is inelegant (reading the LoongArch-KVM-defined CPUCFG leaf only to find it's not KVM) and utterly makes the definition here *not* KVM-specific. [1]: https://github.com/riscv-non-isa/riscv-sbi-doc/blob/v2.0/src/ext-base.adoc My take on this: To check if we are running on Linux KVM or not, first check IOCSR 0x8 (``LOONGARCH_IOCSR_FEATURES``) for bit 11 (``IOCSRF_VM``); we are running under a hypervisor if the bit is set. Then invoke ``HVCL 0`` to find out the hypervisor implementation ID; a return value in ``$a0`` of 0x004d564b (``KVM\0``) means Linux KVM, in which case the rest of the convention applies. > + > +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 architectural state except ``$a0`` is preserved. Or is the whole ``$a0 - $t8`` range clobbered, just like with Linux syscalls? > + > +The parameters are as follows: > + > + ======== ================ ================ > + Register IN OUT > + ======== ================ ================ > + a0 function number Return code > + a1 1st parameter - > + a2 2nd parameter - > + a3 3rd parameter - > + a4 4th parameter - > + a5 5th parameter - > + ======== ================ ================ > + > +Return codes can be as follows: > + > + ==== ========================= > + Code Meaning > + ==== ========================= > + 0 Success > + -1 Hypercall not implemented > + -2 Hypercall parameter error What about re-using well-known errno's, like -ENOSYS for "hypercall not implemented" and -EINVAL for "invalid parameter"? This could save people some hair when more error codes are added in the future. > + ==== ========================= > + > +KVM Hypercalls Documentation > +============================ > + > +The template for each hypercall is: > +1. Hypercall name > +2. Purpose > + > +1. KVM_HCALL_FUNC_PV_IPI > +------------------------ > + > +:Purpose: Send IPIs to multiple vCPUs. > + > +- a0: KVM_HCALL_FUNC_PV_IPI > +- a1: lower part of the bitmap of destination physical CPUIDs > +- a2: higher part of the bitmap of destination physical CPUIDs > +- a3: the lowest physical CPUID in bitmap "CPU ID", instead of "CPUID" for clarity: I suppose most people reading this also know about x86, so "CPUID" could evoke the wrong intuition. This function is equivalent to the C signature "void hypcall(int func, u128 mask, int lowest_cpu_id)", which I think is fine, but one can also see that the return value description is missing. > + > +The hypercall lets a guest send multicast IPIs, with at most 128 > +destinations per hypercall. The destinations are represented by a bitmap > +contained in the first two arguments (a1 and a2). Bit 0 of a1 corresponds > +to the physical CPUID in the third argument (a3), bit 1 corresponds to the > +physical ID a3+1, and so on. > diff --git a/Documentation/virt/kvm/loongarch/index.rst b/Documentation/virt/kvm/loongarch/index.rst > new file mode 100644 > index 000000000000..83387b4c5345 > --- /dev/null > +++ b/Documentation/virt/kvm/loongarch/index.rst > @@ -0,0 +1,10 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +========================= > +KVM for LoongArch systems > +========================= > + > +.. toctree:: > + :maxdepth: 2 > + > + hypercalls.rst
On 2024/3/2 下午5:41, WANG Xuerui wrote: > On 3/2/24 16:47, Bibo Mao wrote: >> Add documentation topic for using pv_virt when running as a guest >> on KVM hypervisor. >> >> Signed-off-by: Bibo Mao <maobibo@loongson.cn> >> --- >> Documentation/virt/kvm/index.rst | 1 + >> .../virt/kvm/loongarch/hypercalls.rst | 79 +++++++++++++++++++ >> Documentation/virt/kvm/loongarch/index.rst | 10 +++ >> 3 files changed, 90 insertions(+) >> create mode 100644 Documentation/virt/kvm/loongarch/hypercalls.rst >> create mode 100644 Documentation/virt/kvm/loongarch/index.rst >> >> diff --git a/Documentation/virt/kvm/index.rst >> b/Documentation/virt/kvm/index.rst >> index ad13ec55ddfe..9ca5a45c2140 100644 >> --- a/Documentation/virt/kvm/index.rst >> +++ b/Documentation/virt/kvm/index.rst >> @@ -14,6 +14,7 @@ KVM >> s390/index >> ppc-pv >> x86/index >> + loongarch/index >> locking >> vcpu-requests >> diff --git a/Documentation/virt/kvm/loongarch/hypercalls.rst >> b/Documentation/virt/kvm/loongarch/hypercalls.rst >> new file mode 100644 >> index 000000000000..1679e48d67d2 >> --- /dev/null >> +++ b/Documentation/virt/kvm/loongarch/hypercalls.rst >> @@ -0,0 +1,79 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> +=================================== >> +The LoongArch paravirtual interface >> +=================================== >> + >> +KVM hypercalls use the HVCL instruction with code 0x100, and the >> hypercall >> +number is put in a0 and up to five arguments may be placed in a1-a5, the >> +return value is placed in v0 (alias with a0). > > Just say a0: the name v0 is long deprecated (has been the case ever > since LoongArch got mainlined). > Sure, will modify since you are compiler export :) >> + >> +The code for that interface can be found in arch/loongarch/kvm/* >> + >> +Querying for existence >> +====================== >> + >> +To find out if we're running on KVM or not, cpucfg can be used with >> index >> +CPUCFG_KVM_BASE (0x40000000), cpucfg range between 0x40000000 - >> 0x400000FF >> +is marked as a specially reserved range. All existing and future >> processors >> +will not implement any features in this range. >> + >> +When Linux is running on KVM, cpucfg with index CPUCFG_KVM_BASE >> (0x40000000) >> +returns magic string "KVM\0" >> + >> +Once you determined you're running under a PV capable KVM, you can >> now use >> +hypercalls as described below. > > So this is still the approach similar to the x86 CPUID-based > implementation. But here the non-privileged behavior isn't specified -- > I see there is PLV checking in Patch 3 but it's safer to have the > requirement spelled out here too. > > But I still think this approach touches more places than strictly > needed. As it is currently the case in > arch/loongarch/kernel/cpu-probe.c, the FEATURES IOCSR is checked for a > bit IOCSRF_VM that already signifies presence of a hypervisor; if this > information can be interpreted as availability of the HVCL instruction > (which I suppose is the case -- a hypervisor can always trap-and-emulate > in case HVCL isn't provided by hardware), here we can already start > making calls with HVCL. > > We can and should define a uniform interface for probing the hypervisor > kind, similar to the centrally-managed RISC-V SBI implementation ID > registry [1]: otherwise future non-KVM hypervisors would have to > > 1. somehow pretend they are KVM and eventually fail to do so, leading to > subtle incompatibilities, > 2. invent another way of probing for their existence, > 3. piggy-back on the current KVM definition, which is inelegant (reading > the LoongArch-KVM-defined CPUCFG leaf only to find it's not KVM) and > utterly makes the definition here *not* KVM-specific. > > [1]: > https://github.com/riscv-non-isa/riscv-sbi-doc/blob/v2.0/src/ext-base.adoc > Sorry, I know nothing about riscv. Can you describe how sbi_get_mimpid() is implemented in detailed? Is it a simple library or need trap into secure mode or need trap into hypervisor mode? > My take on this: > > To check if we are running on Linux KVM or not, first check IOCSR 0x8 > (``LOONGARCH_IOCSR_FEATURES``) for bit 11 (``IOCSRF_VM``); we are > running under a hypervisor if the bit is set. Then invoke ``HVCL 0`` to > find out the hypervisor implementation ID; a return value in ``$a0`` of > 0x004d564b (``KVM\0``) means Linux KVM, in which case the rest of the > convention applies. > I do not think so. `HVCL 0` requires that hypercall ABIs need be unified for all hypervisors. Instead it is not necessary, each hypervisor can has its own hypercall ABI. >> + >> +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? > 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? It seems that with linux Loongarch syscall, t0--t8 are clobber rather than a0-t8. Am I wrong? >> + >> +The parameters are as follows: >> + >> + ======== ================ ================ >> + Register IN OUT >> + ======== ================ ================ >> + a0 function number Return code >> + a1 1st parameter - >> + a2 2nd parameter - >> + a3 3rd parameter - >> + a4 4th parameter - >> + a5 5th parameter - >> + ======== ================ ================ >> + >> +Return codes can be as follows: >> + >> + ==== ========================= >> + Code Meaning >> + ==== ========================= >> + 0 Success >> + -1 Hypercall not implemented >> + -2 Hypercall parameter error > > What about re-using well-known errno's, like -ENOSYS for "hypercall not > implemented" and -EINVAL for "invalid parameter"? This could save people > some hair when more error codes are added in the future. > No, I do not think so. Here is hypercall return value, some OS need see it. -ENOSYS/-EINVAL may be not understandable for non-Linux OS. >> + ==== ========================= >> + >> +KVM Hypercalls Documentation >> +============================ >> + >> +The template for each hypercall is: >> +1. Hypercall name >> +2. Purpose >> + >> +1. KVM_HCALL_FUNC_PV_IPI >> +------------------------ >> + >> +:Purpose: Send IPIs to multiple vCPUs. >> + >> +- a0: KVM_HCALL_FUNC_PV_IPI >> +- a1: lower part of the bitmap of destination physical CPUIDs >> +- a2: higher part of the bitmap of destination physical CPUIDs >> +- a3: the lowest physical CPUID in bitmap > > "CPU ID", instead of "CPUID" for clarity: I suppose most people reading > this also know about x86, so "CPUID" could evoke the wrong intuition. > Both "CPU core id" or "CPUID" are ok for me since there is csr register named LOONGARCH_CSR_CPUID already. > This function is equivalent to the C signature "void hypcall(int func, > u128 mask, int lowest_cpu_id)", which I think is fine, but one can also > see that the return value description is missing. > Sure, the return value description will added. And it is not equivalent to the C signature "void hypcall(int func, u128 mask, int lowest_cpu_id)". int/u128/stucture is not permitted with hypercall ABI, all parameter is "unsigned long". Regards Bibo Mao >> + >> +The hypercall lets a guest send multicast IPIs, with at most 128 >> +destinations per hypercall. The destinations are represented by a >> bitmap >> +contained in the first two arguments (a1 and a2). Bit 0 of a1 >> corresponds >> +to the physical CPUID in the third argument (a3), bit 1 corresponds >> to the >> +physical ID a3+1, and so on. >> diff --git a/Documentation/virt/kvm/loongarch/index.rst >> b/Documentation/virt/kvm/loongarch/index.rst >> new file mode 100644 >> index 000000000000..83387b4c5345 >> --- /dev/null >> +++ b/Documentation/virt/kvm/loongarch/index.rst >> @@ -0,0 +1,10 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> +========================= >> +KVM for LoongArch systems >> +========================= >> + >> +.. toctree:: >> + :maxdepth: 2 >> + >> + hypercalls.rst >
diff --git a/Documentation/virt/kvm/index.rst b/Documentation/virt/kvm/index.rst index ad13ec55ddfe..9ca5a45c2140 100644 --- a/Documentation/virt/kvm/index.rst +++ b/Documentation/virt/kvm/index.rst @@ -14,6 +14,7 @@ KVM s390/index ppc-pv x86/index + loongarch/index locking vcpu-requests diff --git a/Documentation/virt/kvm/loongarch/hypercalls.rst b/Documentation/virt/kvm/loongarch/hypercalls.rst new file mode 100644 index 000000000000..1679e48d67d2 --- /dev/null +++ b/Documentation/virt/kvm/loongarch/hypercalls.rst @@ -0,0 +1,79 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +The LoongArch paravirtual interface +=================================== + +KVM hypercalls use the HVCL instruction with code 0x100, and the hypercall +number is put in a0 and up to five arguments may be placed in a1-a5, the +return value is placed in v0 (alias with a0). + +The code for that interface can be found in arch/loongarch/kvm/* + +Querying for existence +====================== + +To find out if we're running on KVM or not, cpucfg can be used with index +CPUCFG_KVM_BASE (0x40000000), cpucfg range between 0x40000000 - 0x400000FF +is marked as a specially reserved range. All existing and future processors +will not implement any features in this range. + +When Linux is running on KVM, cpucfg with index CPUCFG_KVM_BASE (0x40000000) +returns magic string "KVM\0" + +Once you determined you're running under a PV capable KVM, you can now use +hypercalls as described below. + +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. + +The parameters are as follows: + + ======== ================ ================ + Register IN OUT + ======== ================ ================ + a0 function number Return code + a1 1st parameter - + a2 2nd parameter - + a3 3rd parameter - + a4 4th parameter - + a5 5th parameter - + ======== ================ ================ + +Return codes can be as follows: + + ==== ========================= + Code Meaning + ==== ========================= + 0 Success + -1 Hypercall not implemented + -2 Hypercall parameter error + ==== ========================= + +KVM Hypercalls Documentation +============================ + +The template for each hypercall is: +1. Hypercall name +2. Purpose + +1. KVM_HCALL_FUNC_PV_IPI +------------------------ + +:Purpose: Send IPIs to multiple vCPUs. + +- a0: KVM_HCALL_FUNC_PV_IPI +- a1: lower part of the bitmap of destination physical CPUIDs +- a2: higher part of the bitmap of destination physical CPUIDs +- a3: the lowest physical CPUID in bitmap + +The hypercall lets a guest send multicast IPIs, with at most 128 +destinations per hypercall. The destinations are represented by a bitmap +contained in the first two arguments (a1 and a2). Bit 0 of a1 corresponds +to the physical CPUID in the third argument (a3), bit 1 corresponds to the +physical ID a3+1, and so on. diff --git a/Documentation/virt/kvm/loongarch/index.rst b/Documentation/virt/kvm/loongarch/index.rst new file mode 100644 index 000000000000..83387b4c5345 --- /dev/null +++ b/Documentation/virt/kvm/loongarch/index.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +KVM for LoongArch systems +========================= + +.. toctree:: + :maxdepth: 2 + + hypercalls.rst