Re: [PATCH v16 05/30] LoongArch: KVM: Add vcpu related header files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023/7/14 17:22, Huacai Chen wrote:
Hi, Bibo,

On Fri, Jul 14, 2023 at 3:45 PM bibo mao <maobibo@xxxxxxxxxxx> wrote:



在 2023/7/14 15:11, Huacai Chen 写道:
Hi, Tianrui,

On Thu, Jun 29, 2023 at 3:55 PM Tianrui Zhao <zhaotianrui@xxxxxxxxxxx> wrote:

Add LoongArch vcpu related header files, including vcpu csr
information, irq number defines, and some vcpu interfaces.

Reviewed-by: Bibo Mao <maobibo@xxxxxxxxxxx>
Signed-off-by: Tianrui Zhao <zhaotianrui@xxxxxxxxxxx>
---
  arch/loongarch/include/asm/insn-def.h  |  55 ++++++
  arch/loongarch/include/asm/kvm_csr.h   | 231 +++++++++++++++++++++++++
  arch/loongarch/include/asm/kvm_vcpu.h  |  97 +++++++++++
  arch/loongarch/include/asm/loongarch.h |  20 ++-
  arch/loongarch/kvm/trace.h             | 168 ++++++++++++++++++
  5 files changed, 566 insertions(+), 5 deletions(-)
  create mode 100644 arch/loongarch/include/asm/insn-def.h
  create mode 100644 arch/loongarch/include/asm/kvm_csr.h
  create mode 100644 arch/loongarch/include/asm/kvm_vcpu.h
  create mode 100644 arch/loongarch/kvm/trace.h

diff --git a/arch/loongarch/include/asm/insn-def.h b/arch/loongarch/include/asm/insn-def.h
new file mode 100644
index 000000000000..e285ee108fb0
--- /dev/null
+++ b/arch/loongarch/include/asm/insn-def.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ASM_INSN_DEF_H
+#define __ASM_INSN_DEF_H
+
+#include <linux/stringify.h>
+#include <asm/gpr-num.h>
+#include <asm/asm.h>
+
+#define INSN_STR(x)            __stringify(x)
+#define CSR_RD_SHIFT           0
+#define CSR_RJ_SHIFT           5
+#define CSR_SIMM14_SHIFT       10
+#define CSR_OPCODE_SHIFT       24
As all needed instructions have already upstream in binutils now and
binutils 2.41 will be released soon, I suggest again to introduce
AS_HAS_LVZ_EXTENSION and make KVM depend on AS_HAS_LVZ_EXTENSION.
It is a good news that binutils 2.41 has supported LVZ assemble language.
we will add AS_HAS_LVZ_EXTENSION support, however KVM need not depend on
AS_HAS_LVZ_EXTENSION since bintuils 2.41 is not popularly used. yeap we
need write beautiful code, also we should write code with pratical usage.
1, For pure upstream: the CI toolchain comes from
https://mirrors.edge.kernel.org/pub/tools/crosstool/. Since binutils
2.41 will be released soon, CI toolchain will also be updated soon.

2, For community distributions, such as Fedora rawhide, Debian
unstable and Arch: they usually choose the latest released version, so
binutils 2.41 will be used quickly.

You seem to have missed CLFS for LoongArch [1] and Gentoo [2] ;-)

These two distros are also very punctual in adopting new toolchain versions: the maintainer of CLFS for LoongArch is Loongson employee himself (and he's the author of the Fedora LoongArch Remix too), while the Gentoo toolchain team usually follow the upstream release very quickly. (I happen to maintain the Gentoo loong port too, and also am a member of gentoo-toolchain team.)

[1]: https://github.com/sunhaiyong1978/CLFS-for-LoongArch
[2]: https://wiki.gentoo.org/wiki/Project:LoongArch


3, For downstream distributions, such as UOS and Kylin: if they choose
kernel as new as 6.6, they may probably choose binutils as new as
2.41; if they choose an LTS kernel (e.g., 6.1), they should backport
KVM support to the kernel, then they don't have any reason to not
backport LVZ instructions support to binutils.

I generally agree with Huacai here. If those distros pick bleeding-edge kernel releases then they have no reason to not also bump the toolchain baseline too; otherwise they must be backporting. In which case they either:

a) pull patches from v6.6, so they may as well integrate the binutils patches along the way (trivial compared to kernel backports), or b) ask Loongson to provide the patches, in which case you may just give this version of code to them, which can be done (and I assume, has already been done) without any upstream involvement.

All in all I don't see a reason for hardcoding any opcode in this particular time, when everyone involved agrees on moving fast.

--
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux