2:08 p.m.
From: lixianglai <lixianglai(a)loongson.cn>
Hello, Everyone:
This patch series adds libvirt support for loongarch.Although the bios
path and name has not been officially integrated into qemu and we think
there are still many shortcomings, we try to push a version of patch to
the community according to the opinions of the community, hoping to
listen to everyone's opinions. Anyway we have a version of libvirt that
supports loongarch.
You can also get libvirt's patch from the link below:
https://gitlab.com/lixianglai/libvirt
branch: loongarch
Since the patch associated with loongarch has not yet been submitted to
the virt-manager community, we are providing a temporary patch with
loongarch for the time being patch's virt-manager, the open source work
of virt-manager adding loongarch will be followed up later or
synchronized with the open source libvirt.
You can get the virt-manager code with loongarch patch from the link below:
https://github.com/loongson/virt-manager
branch: loongarch
loongarch's virtual machine bios is not yet available in qemu, so you can get it
from the following link
https://github.com/loongson/Firmware/tree/main/LoongArchVirtMachine
(Note: You should clone the repository using git instead of downloading the file via wget
or you'll get xml)
We named the bios edk2-loongarch64-code.fd, edk2-loongarch64-vars.fd is used to store
pflash images of non-volatile
variables.After installing qemu-system-loongarch64, you need to manually copy these two
files to the /user/share/qemu
directory.
Since there is no fedora operating system that supports the loongarch
architecture, you can find an iso that supports loongarch at the link
below for testing purposes:
https://github.com/fedora-remix-loongarch/releases-info
Well, if you have completed the above steps I think you can now install loongarch
virtual machine,
you can install it through the virt-manager graphical interface, or install it through
vrit-install,
here is an example of installing it using virt-install:
virt-install \
--virt-type=qemu \
--name loongarch-test \
--memory 4096 \
--vcpus=4 \
--arch=loongarch64 \
--boot cdrom \
--disk device=cdrom,bus=scsi,path=/root/livecd-fedora-mate-4.loongarch64.iso \
--disk
path=/var/lib/libvirt/images/debian12-loongarch64.qcow2,size=10,format=qcow2,bus=scsi \
--network network=default \
--osinfo archlinux \
--feature acpi=true \
--video=virtio \
--graphics=vnc,listen=0.0.0.0
lixianglai (5):
Add loongarch cpu support
Add loongarch cpu model and vendor info
Config some capabilities for loongarch virt machine
Implement the method of getting host info for loongarch
Add bios path for loongarch
po/POTFILES | 1 +
src/conf/schemas/basictypes.rng | 1 +
src/cpu/cpu.c | 2 +
src/cpu/cpu.h | 2 +
src/cpu/cpu_loongarch.c | 742 +++++++++++++++++++++++++++++
src/cpu/cpu_loongarch.h | 25 +
src/cpu/cpu_loongarch_data.h | 37 ++
src/cpu/meson.build | 1 +
src/cpu_map/index.xml | 5 +
src/cpu_map/loongarch_la464.xml | 6 +
src/cpu_map/loongarch_vendors.xml | 3 +
src/cpu_map/meson.build | 2 +
src/qemu/qemu.conf.in | 3 +-
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_conf.c | 3 +-
src/qemu/qemu_domain.c | 32 ++
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_domain_address.c | 55 +++
src/qemu/qemu_validate.c | 2 +-
src/qemu/test_libvirtd_qemu.aug.in | 1 +
src/util/virarch.c | 4 +
src/util/virarch.h | 4 +
src/util/virhostcpu.c | 4 +-
src/util/virsysinfo.c | 5 +-
24 files changed, 940 insertions(+), 7 deletions(-)
create mode 100644 src/cpu/cpu_loongarch.c
create mode 100644 src/cpu/cpu_loongarch.h
create mode 100644 src/cpu/cpu_loongarch_data.h
create mode 100644 src/cpu_map/loongarch_la464.xml
create mode 100644 src/cpu_map/loongarch_vendors.xml
--
2.27.0
2:08 p.m.
New subject: [libvirt PATCH 1/5] Add loongarch cpu support
From: lixianglai <lixianglai(a)loongson.cn>
Add loongarch cpu support, Define new cpu type 'loongarch64'
and implement it's driver functions.
Signed-off-by: lixianglai <lixianglai(a)loongson.cn>
---
po/POTFILES | 1 +
src/conf/schemas/basictypes.rng | 1 +
src/cpu/cpu.c | 2 +
src/cpu/cpu.h | 2 +
src/cpu/cpu_loongarch.c | 742 ++++++++++++++++++++++++++++++++
src/cpu/cpu_loongarch.h | 25 ++
src/cpu/cpu_loongarch_data.h | 37 ++
src/cpu/meson.build | 1 +
src/qemu/qemu_capabilities.c | 1 +
src/qemu/qemu_domain.c | 4 +
src/util/virarch.c | 2 +
src/util/virarch.h | 4 +
12 files changed, 822 insertions(+)
create mode 100644 src/cpu/cpu_loongarch.c
create mode 100644 src/cpu/cpu_loongarch.h
create mode 100644 src/cpu/cpu_loongarch_data.h
diff --git a/po/POTFILES b/po/POTFILES
index 3a51aea5cb..c0e66d563e 100644
--- a/po/POTFILES
+++ b/po/POTFILES
@@ -70,6 +70,7 @@ src/cpu/cpu.c
src/cpu/cpu_arm.c
src/cpu/cpu_map.c
src/cpu/cpu_ppc64.c
+src/cpu/cpu_loongarch.c
src/cpu/cpu_riscv64.c
src/cpu/cpu_s390.c
src/cpu/cpu_x86.c
diff --git a/src/conf/schemas/basictypes.rng b/src/conf/schemas/basictypes.rng
index 26eb538077..04f032b3ab 100644
--- a/src/conf/schemas/basictypes.rng
+++ b/src/conf/schemas/basictypes.rng
@@ -470,6 +470,7 @@
<value>x86_64</value>
<value>xtensa</value>
<value>xtensaeb</value>
+ <value>loongarch64</value>
</choice>
</define>
diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c
index bc43aa4e93..1e7c879ca5 100644
--- a/src/cpu/cpu.c
+++ b/src/cpu/cpu.c
@@ -27,6 +27,7 @@
#include "cpu_ppc64.h"
#include "cpu_s390.h"
#include "cpu_arm.h"
+#include "cpu_loongarch.h"
#include "cpu_riscv64.h"
#include "capabilities.h"
@@ -41,6 +42,7 @@ static struct cpuArchDriver *drivers[] = {
&cpuDriverS390,
&cpuDriverArm,
&cpuDriverRiscv64,
+ &cpuDriverLoongArch,
};
diff --git a/src/cpu/cpu.h b/src/cpu/cpu.h
index a4cdb37f03..9ec0a109b8 100644
--- a/src/cpu/cpu.h
+++ b/src/cpu/cpu.h
@@ -27,6 +27,7 @@
#include "cpu_x86_data.h"
#include "cpu_ppc64_data.h"
#include "cpu_arm_data.h"
+#include "cpu_loongarch_data.h"
typedef struct _virCPUData virCPUData;
@@ -36,6 +37,7 @@ struct _virCPUData {
virCPUx86Data x86;
virCPUppc64Data ppc64;
virCPUarmData arm;
+ virCPULoongArchData loongarch;
/* generic driver needs no data */
} data;
};
diff --git a/src/cpu/cpu_loongarch.c b/src/cpu/cpu_loongarch.c
new file mode 100644
index 0000000000..0f96535606
--- /dev/null
+++ b/src/cpu/cpu_loongarch.c
@@ -0,0 +1,742 @@
+/*
+ * cpu_loongarch.c: CPU driver for 64-bit LOONGARCH CPUs
+ *
+ * Copyright (C) 2023 Loongson Technology.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library. If not, see
+ * <http://www.gnu.org/licenses/>;.
+ */
+
+#include <config.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <sys/time.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include "virlog.h"
+#include "viralloc.h"
+#include "cpu.h"
+#include "virstring.h"
+#include "cpu_map.h"
+#include "virbuffer.h"
+
+#define VIR_FROM_THIS VIR_FROM_CPU
+
+VIR_LOG_INIT("cpu.cpu_loongarch");
+
+static const virArch archs[] = { VIR_ARCH_LOONGARCH64 };
+
+typedef struct _virCPULoongArchVendor virCPULoongArchVendor;
+struct _virCPULoongArchVendor {
+ char *name;
+};
+
+typedef struct _virCPULoongArchModel virCPULoongArchModel;
+struct _virCPULoongArchModel {
+ char *name;
+ const virCPULoongArchVendor *vendor;
+ virCPULoongArchData data;
+};
+
+typedef struct _virCPULoongArchMap virCPULoongArchMap;
+struct _virCPULoongArchMap {
+ size_t nvendors;
+ virCPULoongArchVendor **vendors;
+ size_t nmodels;
+ virCPULoongArchModel **models;
+};
+
+static void
+virCPULoongArchDataClear(virCPULoongArchData *data)
+{
+ if (!data)
+ return;
+
+ VIR_FREE(data->prid);
+}
+
+static int
+virCPULoongArchDataCopy(virCPULoongArchData *dst,
+ const virCPULoongArchData *src)
+{
+ size_t i;
+
+ dst->prid = g_new0(virCPULoongArchPrid, src->len);
+ if (!dst->prid)
+ return -1;
+
+ dst->len = src->len;
+
+ for (i = 0; i < src->len; i++) {
+ dst->prid[i].value = src->prid[i].value;
+ dst->prid[i].mask = src->prid[i].mask;
+ }
+
+ return 0;
+}
+
+static void
+virCPULoongArchVendorFree(virCPULoongArchVendor *vendor)
+{
+ if (!vendor)
+ return;
+
+ VIR_FREE(vendor->name);
+ VIR_FREE(vendor);
+}
+
+static virCPULoongArchVendor *
+virCPULoongArchVendorFind(const virCPULoongArchMap *map,
+ const char *name)
+{
+ size_t i;
+
+ for (i = 0; i < map->nvendors; i++) {
+ if (STREQ(map->vendors[i]->name, name))
+ return map->vendors[i];
+ }
+
+ return NULL;
+}
+
+static void
+virCPULoongArchModelFree(virCPULoongArchModel *model)
+{
+ if (!model)
+ return;
+
+ virCPULoongArchDataClear(&model->data);
+ VIR_FREE(model->name);
+ VIR_FREE(model);
+}
+
+static virCPULoongArchModel *
+virCPULoongArchModelCopy(const virCPULoongArchModel *model)
+{
+ virCPULoongArchModel *copy;
+
+ copy = g_new0(virCPULoongArchModel, 1);
+ if (!copy)
+ goto cleanup;
+
+ copy->name = g_strdup(model->name);
+
+ if (virCPULoongArchDataCopy(©->data, &model->data) < 0)
+ goto cleanup;
+
+ copy->vendor = model->vendor;
+
+ return copy;
+
+ cleanup:
+ virCPULoongArchModelFree(copy);
+ return NULL;
+}
+
+static virCPULoongArchModel *
+virCPULoongArchModelFind(const virCPULoongArchMap *map,
+ const char *name)
+{
+ size_t i;
+
+ for (i = 0; i < map->nmodels; i++) {
+ if (STREQ(map->models[i]->name, name))
+ return map->models[i];
+ }
+
+ return NULL;
+}
+
+static virCPULoongArchModel *
+virCPULoongArchModelFindPrid(const virCPULoongArchMap *map,
+ uint32_t prid)
+{
+ size_t i;
+ size_t j;
+
+ for (i = 0; i < map->nmodels; i++) {
+ virCPULoongArchModel *model = map->models[i];
+ for (j = 0; j < model->data.len; j++) {
+ if ((prid & model->data.prid[j].mask) ==
model->data.prid[j].value)
+ return model;
+ }
+ }
+
+ return NULL;
+}
+
+static virCPULoongArchModel *
+virCPULoongArchModelFromCPU(const virCPUDef *cpu,
+ const virCPULoongArchMap *map)
+{
+ virCPULoongArchModel *model;
+
+ if (!cpu->model) {
+ virReportError(VIR_ERR_INVALID_ARG, "%s",
+ _("no CPU model specified"));
+ return NULL;
+ }
+
+ if (!(model = virCPULoongArchModelFind(map, cpu->model))) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Unknown CPU model %1$s"), cpu->model);
+ return NULL;
+ }
+
+ return virCPULoongArchModelCopy(model);
+}
+
+static void
+virCPULoongArchMapFree(virCPULoongArchMap *map)
+{
+ size_t i;
+
+ if (!map)
+ return;
+
+ for (i = 0; i < map->nmodels; i++)
+ virCPULoongArchModelFree(map->models[i]);
+ VIR_FREE(map->models);
+
+ for (i = 0; i < map->nvendors; i++)
+ virCPULoongArchVendorFree(map->vendors[i]);
+ VIR_FREE(map->vendors);
+
+ VIR_FREE(map);
+}
+
+static int
+virCPULoongArchVendorParse(xmlXPathContextPtr ctxt ATTRIBUTE_UNUSED,
+ const char *name,
+ void *data)
+{
+ virCPULoongArchMap *map = data;
+ virCPULoongArchVendor *vendor;
+ int ret = -1;
+
+ vendor = g_new0(virCPULoongArchVendor, 1);
+ if (!vendor)
+ return ret;
+ vendor->name = g_strdup(name);
+
+ if (virCPULoongArchVendorFind(map, vendor->name)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("CPU vendor %1$s already defined"), vendor->name);
+ goto cleanup;
+ }
+
+ VIR_APPEND_ELEMENT(map->vendors, map->nvendors, vendor);
+
+ ret = 0;
+
+ cleanup:
+ virCPULoongArchVendorFree(vendor);
+ return ret;
+}
+
+static int
+virCPULoongArchModelParse(xmlXPathContextPtr ctxt,
+ const char *name,
+ void *data)
+{
+ virCPULoongArchMap *map = data;
+ virCPULoongArchModel *model;
+ xmlNodePtr *nodes = NULL;
+ char *vendor = NULL;
+ uint32_t prid;
+ size_t i;
+ int n;
+ int ret = -1;
+
+ model = g_new0(virCPULoongArchModel, 1);
+ if (!model)
+ goto cleanup;
+
+ model->name = g_strdup(name);
+
+ if (virCPULoongArchModelFind(map, model->name)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("CPU model %1$s already defined"), model->name);
+ goto cleanup;
+ }
+
+ if (virXPathBoolean("boolean(./vendor)", ctxt)) {
+ vendor = virXPathString("string(./vendor/@name)", ctxt);
+ if (!vendor) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Invalid vendor element in CPU model %1$s"),
+ model->name);
+ goto cleanup;
+ }
+
+ if (!(model->vendor = virCPULoongArchVendorFind(map, vendor))) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Unknown vendor %1$s referenced by CPU model
%2$s"),
+ vendor, model->name);
+ goto cleanup;
+ }
+ }
+
+ if ((n = virXPathNodeSet("./prid", ctxt, &nodes)) <= 0) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Missing Prid information for CPU model %1$s"),
+ model->name);
+ goto cleanup;
+ }
+
+ model->data.prid = g_new0(virCPULoongArchPrid, n);
+ if (!model->data.prid)
+ goto cleanup;
+
+ model->data.len = n;
+
+ for (i = 0; i < n; i++) {
+
+ if (virXMLPropUInt(nodes[i], "value", 16, VIR_XML_PROP_REQUIRED,
+ &prid) < 0)
+ {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Missing or invalid Prid value in CPU model
%1$s"),
+ model->name);
+ goto cleanup;
+ }
+ model->data.prid[i].value = prid;
+
+ if (virXMLPropUInt(nodes[i], "mask", 16, VIR_XML_PROP_REQUIRED,
+ &prid) < 0)
+ {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Missing or invalid PVR mask in CPU model %1$s"),
+ model->name);
+ goto cleanup;
+ }
+ model->data.prid[i].mask = prid;
+ }
+
+ VIR_APPEND_ELEMENT(map->models, map->nmodels, model);
+
+ ret = 0;
+
+ cleanup:
+ virCPULoongArchModelFree(model);
+ VIR_FREE(vendor);
+ VIR_FREE(nodes);
+ return ret;
+}
+
+static virCPULoongArchMap *
+virCPULoongArchLoadMap(void)
+{
+ virCPULoongArchMap *map;
+
+ map = g_new0(virCPULoongArchMap, 1);
+ if (!map)
+ goto cleanup;
+
+ if (cpuMapLoad("loongarch64", virCPULoongArchVendorParse, NULL,
+ virCPULoongArchModelParse, map) < 0)
+ goto cleanup;
+
+ return map;
+
+ cleanup:
+ virCPULoongArchMapFree(map);
+ return NULL;
+}
+
+static virCPUData *
+virCPULoongArchMakeCPUData(virArch arch,
+ virCPULoongArchData *data)
+{
+ virCPUData * cpuData;
+
+ cpuData = g_new0(virCPUData, 1);
+ if (!cpuData)
+ return NULL;
+
+ cpuData->arch = arch;
+
+ if (virCPULoongArchDataCopy(&cpuData->data.loongarch, data) < 0)
+ VIR_FREE(cpuData);
+
+ return cpuData;
+}
+
+static virCPUCompareResult
+virCPULoongArchCompute(virCPUDef *host,
+ const virCPUDef *other,
+ virCPUData **guestData,
+ char **message)
+{
+ virCPULoongArchMap *map = NULL;
+ virCPULoongArchModel *host_model = NULL;
+ virCPULoongArchModel *guest_model = NULL;
+ virCPUDef *cpu = NULL;
+ virCPUCompareResult ret = VIR_CPU_COMPARE_ERROR;
+ virArch arch;
+ size_t i;
+
+ /* Ensure existing configurations are handled correctly */
+ if (!(cpu = virCPUDefCopy(other)))
+ goto cleanup;
+
+ if (cpu->arch != VIR_ARCH_NONE) {
+ bool found = false;
+
+ for (i = 0; i < G_N_ELEMENTS(archs); i++) {
+ if (archs[i] == cpu->arch) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found) {
+ VIR_DEBUG("CPU arch %s does not match host arch",
+ virArchToString(cpu->arch));
+ if (message) {
+ *message = g_strdup_printf(_("CPU arch %1$s does not match host
arch"),
+ virArchToString(cpu->arch));
+ }
+ ret = VIR_CPU_COMPARE_INCOMPATIBLE;
+ goto cleanup;
+ }
+ arch = cpu->arch;
+ } else {
+ arch = host->arch;
+ }
+
+ if (cpu->vendor &&
+ (!host->vendor || STRNEQ(cpu->vendor, host->vendor))) {
+ VIR_DEBUG("host CPU vendor does not match required CPU vendor %s",
+ cpu->vendor);
+ if (message) {
+ *message = g_strdup_printf(_("host CPU vendor does not match required
CPU vendor %1$s"),
+ cpu->vendor);
+ }
+ ret = VIR_CPU_COMPARE_INCOMPATIBLE;
+ goto cleanup;
+ }
+
+ if (!(map = virCPULoongArchLoadMap()))
+ goto cleanup;
+
+ /* Host CPU information */
+ if (!(host_model = virCPULoongArchModelFromCPU(host, map)))
+ goto cleanup;
+
+ if (cpu->type == VIR_CPU_TYPE_GUEST) {
+ /* Guest CPU information */
+ switch (cpu->mode) {
+ case VIR_CPU_MODE_HOST_MODEL:
+ case VIR_CPU_MODE_HOST_PASSTHROUGH:
+ /* host-model and host-passthrough:
+ * the guest CPU is the same as the host */
+ guest_model = virCPULoongArchModelCopy(host_model);
+ break;
+
+ case VIR_CPU_MODE_CUSTOM:
+ /* custom:
+ * look up guest CPU information */
+ guest_model = virCPULoongArchModelFromCPU(cpu, map);
+ break;
+ }
+ } else {
+ /* Other host CPU information */
+ guest_model = virCPULoongArchModelFromCPU(cpu, map);
+ }
+
+ if (!guest_model)
+ goto cleanup;
+
+ if (STRNEQ(guest_model->name, host_model->name)) {
+ VIR_DEBUG("host CPU model does not match required CPU model %s",
+ guest_model->name);
+ if (message) {
+ *message = g_strdup_printf(_("host CPU model does not match required CPU
model %1$s"),
+ guest_model->name);
+ }
+ ret = VIR_CPU_COMPARE_INCOMPATIBLE;
+ goto cleanup;
+ }
+
+ if (guestData)
+ if (!(*guestData = virCPULoongArchMakeCPUData(arch, &guest_model->data)))
+ goto cleanup;
+
+ ret = VIR_CPU_COMPARE_IDENTICAL;
+
+ cleanup:
+ virCPUDefFree(cpu);
+ virCPULoongArchMapFree(map);
+ virCPULoongArchModelFree(host_model);
+ virCPULoongArchModelFree(guest_model);
+ return ret;
+}
+
+static virCPUCompareResult
+virCPULoongArchCompare(virCPUDef *host,
+ virCPUDef *cpu,
+ bool failIncompatible)
+{
+ virCPUCompareResult ret;
+ char *message = NULL;
+
+ if (!host || !host->model) {
+ if (failIncompatible) {
+ virReportError(VIR_ERR_CPU_INCOMPATIBLE, "%s",
+ _("unknown host CPU"));
+ } else {
+ VIR_WARN("unknown host CPU");
+ ret = VIR_CPU_COMPARE_INCOMPATIBLE;
+ }
+ return -1;
+ }
+
+ ret = virCPULoongArchCompute(host, cpu, NULL, &message);
+
+ if (failIncompatible && ret == VIR_CPU_COMPARE_INCOMPATIBLE) {
+ ret = VIR_CPU_COMPARE_ERROR;
+ if (message) {
+ virReportError(VIR_ERR_CPU_INCOMPATIBLE, "%s", message);
+ } else {
+ virReportError(VIR_ERR_CPU_INCOMPATIBLE, NULL);
+ }
+ }
+ VIR_FREE(message);
+
+ return ret;
+}
+
+static int
+virCPULoongArchDriverDecode(virCPUDef *cpu,
+ const virCPUData *data,
+ virDomainCapsCPUModels *models)
+{
+ int ret = -1;
+ virCPULoongArchMap *map;
+ const virCPULoongArchModel *model;
+
+ if (!data || !(map = virCPULoongArchLoadMap()))
+ return -1;
+
+ if (!(model = virCPULoongArchModelFindPrid(map,
data->data.loongarch.prid[0].value))) {
+ virReportError(VIR_ERR_OPERATION_FAILED,
+ _("Cannot find CPU model with Prid 0x%1$08x"),
+ data->data.loongarch.prid[0].value);
+ goto cleanup;
+ }
+
+ if (!virCPUModelIsAllowed(model->name, models)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("CPU model %1$s is not supported by hypervisor"),
+ model->name);
+ goto cleanup;
+ }
+
+ cpu->model = g_strdup(model->name);
+ if (model->vendor) {
+ cpu->vendor = g_strdup(model->vendor->name);
+ }
+ ret = 0;
+
+ cleanup:
+ virCPULoongArchMapFree(map);
+
+ return ret;
+}
+
+static void
+virCPULoongArchDataFree(virCPUData *data)
+{
+ if (!data)
+ return;
+
+ virCPULoongArchDataClear(&data->data.loongarch);
+ VIR_FREE(data);
+}
+
+static int
+virCPULoongArchGetHostPRID(void)
+{
+ return 0x14c010;
+}
+
+static int
+virCPULoongArchGetHost(virCPUDef *cpu,
+ virDomainCapsCPUModels *models)
+{
+ virCPUData *cpuData = NULL;
+ virCPULoongArchData *data;
+ int ret = -1;
+
+ if (!(cpuData = virCPUDataNew(archs[0])))
+ goto cleanup;
+
+ data = &cpuData->data.loongarch;
+ data->prid = g_new0(virCPULoongArchPrid, 1);
+ if (!data->prid)
+ goto cleanup;
+
+
+ data->len = 1;
+
+ data->prid[0].value = virCPULoongArchGetHostPRID();
+ data->prid[0].mask = 0xffff00ul;
+
+ ret = virCPULoongArchDriverDecode(cpu, cpuData, models);
+
+ cleanup:
+ virCPULoongArchDataFree(cpuData);
+ return ret;
+}
+
+
+static int
+virCPULoongArchUpdate(virCPUDef *guest,
+ const virCPUDef *host ATTRIBUTE_UNUSED,
+ bool relative G_GNUC_UNUSED)
+{
+ /*
+ * - host-passthrough doesn't even get here
+ * - host-model is used for host CPU running in a compatibility mode and
+ * it needs to remain unchanged
+ * - custom doesn't support any optional features, there's nothing to
+ * update
+ */
+
+ if (guest->mode == VIR_CPU_MODE_CUSTOM)
+ guest->match = VIR_CPU_MATCH_EXACT;
+
+ return 0;
+}
+
+static virCPUDef *
+virCPULoongArchDriverBaseline(virCPUDef **cpus,
+ unsigned int ncpus,
+ virDomainCapsCPUModels *models ATTRIBUTE_UNUSED,
+ const char **features ATTRIBUTE_UNUSED,
+ bool migratable ATTRIBUTE_UNUSED)
+{
+ virCPULoongArchMap *map;
+ const virCPULoongArchModel *model;
+ const virCPULoongArchVendor *vendor = NULL;
+ virCPUDef *cpu = NULL;
+ size_t i;
+
+ if (!(map = virCPULoongArchLoadMap()))
+ goto error;
+
+ if (!(model = virCPULoongArchModelFind(map, cpus[0]->model))) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Unknown CPU model %1$s"), cpus[0]->model);
+ goto error;
+ }
+
+ for (i = 0; i < ncpus; i++) {
+ const virCPULoongArchVendor *vnd;
+
+ if (STRNEQ(cpus[i]->model, model->name)) {
+ virReportError(VIR_ERR_OPERATION_FAILED, "%s",
+ _("CPUs are incompatible"));
+ goto error;
+ }
+
+ if (!cpus[i]->vendor)
+ continue;
+
+ if (!(vnd = virCPULoongArchVendorFind(map, cpus[i]->vendor))) {
+ virReportError(VIR_ERR_OPERATION_FAILED,
+ _("Unknown CPU vendor %1$s"), cpus[i]->vendor);
+ goto error;
+ }
+
+ if (model->vendor) {
+ if (model->vendor != vnd) {
+ virReportError(VIR_ERR_OPERATION_FAILED,
+ _("CPU vendor %1$s of model %2$s differs from vendor
%3$s"),
+ model->vendor->name, model->name,
+ vnd->name);
+ goto error;
+ }
+ } else if (vendor) {
+ if (vendor != vnd) {
+ virReportError(VIR_ERR_OPERATION_FAILED, "%s",
+ _("CPU vendors do not match"));
+ goto error;
+ }
+ } else {
+ vendor = vnd;
+ }
+ }
+
+ cpu = virCPUDefNew();
+ cpu->model = g_strdup(model->name);
+ if (vendor) {
+ cpu->vendor = g_strdup(vendor->name);
+ }
+ cpu->type = VIR_CPU_TYPE_GUEST;
+ cpu->match = VIR_CPU_MATCH_EXACT;
+ cpu->fallback = VIR_CPU_FALLBACK_FORBID;
+
+ cleanup:
+ virCPULoongArchMapFree(map);
+ return cpu;
+
+ error:
+ virCPUDefFree(cpu);
+ cpu = NULL;
+ goto cleanup;
+}
+
+static int
+virCPULoongArchDriverGetModels(char ***models)
+{
+ virCPULoongArchMap *map;
+ size_t i;
+ int ret = -1;
+
+ if (!(map = virCPULoongArchLoadMap())) {
+ return -1;
+ }
+
+ if (models) {
+ *models = g_new0(char *, map->nmodels + 1);
+ if (!(*models))
+ return -1;
+
+ for (i = 0; i < map->nmodels; i++) {
+ (*models)[i] = g_strdup(map->models[i]->name);
+ }
+ }
+
+ ret = map->nmodels;
+
+ return ret;
+}
+
+struct cpuArchDriver cpuDriverLoongArch = {
+ .name = "LoongArch",
+ .arch = archs,
+ .narch = G_N_ELEMENTS(archs),
+ .compare = virCPULoongArchCompare,
+ .decode = virCPULoongArchDriverDecode,
+ .encode = NULL,
+ .dataFree = virCPULoongArchDataFree,
+ .getHost = virCPULoongArchGetHost,
+ .baseline = virCPULoongArchDriverBaseline,
+ .update = virCPULoongArchUpdate,
+ .getModels = virCPULoongArchDriverGetModels,
+};
diff --git a/src/cpu/cpu_loongarch.h b/src/cpu/cpu_loongarch.h
new file mode 100644
index 0000000000..bebc16a242
--- /dev/null
+++ b/src/cpu/cpu_loongarch.h
@@ -0,0 +1,25 @@
+/*
+ * cpu_loongarch.h: CPU driver for 64-bit LOONGARCH CPUs
+ *
+ * Copyright (C) 2023 Loongson Technology.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library. If not, see
+ * <http://www.gnu.org/licenses/>;.
+ */
+
+#pragma once
+
+# include "cpu.h"
+
+extern struct cpuArchDriver cpuDriverLoongArch;
diff --git a/src/cpu/cpu_loongarch_data.h b/src/cpu/cpu_loongarch_data.h
new file mode 100644
index 0000000000..43ae044838
--- /dev/null
+++ b/src/cpu/cpu_loongarch_data.h
@@ -0,0 +1,37 @@
+/*
+ * cpu_loongarch_data.h: 64-bit LOONGARCH CPU specific data
+ *
+ * Copyright (C) 2023 Loongson Technology.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see
+ * <http://www.gnu.org/licenses/>;.
+ */
+
+#pragma once
+
+# include <stdint.h>
+
+typedef struct _virCPULoongArchPrid virCPULoongArchPrid;
+struct _virCPULoongArchPrid {
+ uint32_t value;
+ uint32_t mask;
+};
+
+# define VIR_CPU_LOONGARCH_DATA_INIT { 0 }
+
+typedef struct _virCPULoongArchData virCPULoongArchData;
+struct _virCPULoongArchData {
+ size_t len;
+ virCPULoongArchPrid *prid;
+};
diff --git a/src/cpu/meson.build b/src/cpu/meson.build
index 55396903b9..254d6b4545 100644
--- a/src/cpu/meson.build
+++ b/src/cpu/meson.build
@@ -6,6 +6,7 @@ cpu_sources = [
'cpu_riscv64.c',
'cpu_s390.c',
'cpu_x86.c',
+ 'cpu_loongarch.c'
]
cpu_lib = static_library(
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 83119e871a..118d3429c3 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2697,6 +2697,7 @@ static const char *preferredMachines[] =
"sim", /* VIR_ARCH_XTENSA */
"sim", /* VIR_ARCH_XTENSAEB */
+ "virt", /* VIR_ARCH_LOONGARCH64 */
};
G_STATIC_ASSERT(G_N_ELEMENTS(preferredMachines) == VIR_ARCH_LAST);
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 953808fcfe..00e38950b6 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4222,6 +4222,10 @@ qemuDomainDefAddDefaultDevices(virQEMUDriver *driver,
addPCIRoot = true;
break;
+ case VIR_ARCH_LOONGARCH64:
+ addPCIeRoot = true;
+ break;
+
case VIR_ARCH_ARMV7B:
case VIR_ARCH_CRIS:
case VIR_ARCH_ITANIUM:
diff --git a/src/util/virarch.c b/src/util/virarch.c
index 01e520de73..289bd80d90 100644
--- a/src/util/virarch.c
+++ b/src/util/virarch.c
@@ -83,6 +83,8 @@ static const struct virArchData {
{ "xtensa", 32, VIR_ARCH_LITTLE_ENDIAN },
{ "xtensaeb", 32, VIR_ARCH_BIG_ENDIAN },
+
+ { "loongarch64", 64, VIR_ARCH_LITTLE_ENDIAN },
};
G_STATIC_ASSERT(G_N_ELEMENTS(virArchData) == VIR_ARCH_LAST);
diff --git a/src/util/virarch.h b/src/util/virarch.h
index 747f77c48e..638e519fe6 100644
--- a/src/util/virarch.h
+++ b/src/util/virarch.h
@@ -69,6 +69,8 @@ typedef enum {
VIR_ARCH_XTENSA, /* XTensa 32 LE
https://en.wikipedia.org/wiki/Xtensa#Processor_Cores */
VIR_ARCH_XTENSAEB, /* XTensa 32 BE
https://en.wikipedia.org/wiki/Xtensa#Processor_Cores */
+ VIR_ARCH_LOONGARCH64, /* LoongArch 64 LE */
+
VIR_ARCH_LAST,
} virArch;
@@ -106,6 +108,8 @@ typedef enum {
#define ARCH_IS_SH4(arch) ((arch) == VIR_ARCH_SH4 ||\
(arch) == VIR_ARCH_SH4EB)
+#define ARCH_IS_LOONGARCH(arch) ((arch) == VIR_ARCH_LOONGARCH64)
+
typedef enum {
VIR_ARCH_LITTLE_ENDIAN,
VIR_ARCH_BIG_ENDIAN,
--
2.27.0
1:42 a.m.
New subject: [libvirt PATCH 1/5] Add loongarch cpu support
On Thu, Dec 14, 2023 at 02:08:45PM +0800, xianglai li wrote:
From: lixianglai <lixianglai(a)loongson.cn>
Add loongarch cpu support, Define new cpu type 'loongarch64'
and implement it's driver functions.
Signed-off-by: lixianglai <lixianglai(a)loongson.cn>
We usually prefer the full name to be used both for git authorship
and DCO purposes. I believe this would be "Xianglai Li" in your case.
---
po/POTFILES | 1 +
src/conf/schemas/basictypes.rng | 1 +
src/cpu/cpu.c | 2 +
src/cpu/cpu.h | 2 +
src/cpu/cpu_loongarch.c | 742 ++++++++++++++++++++++++++++++++
src/cpu/cpu_loongarch.h | 25 ++
src/cpu/cpu_loongarch_data.h | 37 ++
src/cpu/meson.build | 1 +
src/qemu/qemu_capabilities.c | 1 +
src/qemu/qemu_domain.c | 4 +
src/util/virarch.c | 2 +
src/util/virarch.h | 4 +
12 files changed, 822 insertions(+)
create mode 100644 src/cpu/cpu_loongarch.c
create mode 100644 src/cpu/cpu_loongarch.h
create mode 100644 src/cpu/cpu_loongarch_data.h
This patch breaks the test suite:
$ make -C .../libvirt/build/build-aux sc_preprocessor_indentation
make: Entering directory '.../libvirt/build/build-aux'
cppi: .../libvirt/src/cpu/cpu_loongarch.h: line 23: not properly indented
cppi: .../libvirt/src/cpu/cpu_loongarch_data.h: line 23: not properly indented
cppi: .../libvirt/src/cpu/cpu_loongarch_data.h: line 31: not properly indented
incorrect preprocessor indentation
make: *** [.../libvirt/build-aux/syntax-check.mk:500:
sc_preprocessor_indentation] Error 1
make: Leaving directory '.../libvirt/build/build-aux'
Should be an easy enough fix.
Please make sure that 'meson test' runs successfully after every
single patch in the series, and that you have optional test tools
such as cppi installed.
+++ b/src/conf/schemas/basictypes.rng
@@ -470,6 +470,7 @@
<value>x86_64</value>
<value>xtensa</value>
<value>xtensaeb</value>
+ <value>loongarch64</value>
This list is sorted alphabetically; please ensure that it remains
that way after your changes. Not all lists in libvirt are sorted
alphabetically, but generally speaking if you see one that is you
should keep it that way.
+++ b/src/cpu/cpu_loongarch.c
@@ -0,0 +1,742 @@
+static const virArch archs[] = { VIR_ARCH_LOONGARCH64 };
+
+typedef struct _virCPULoongArchVendor virCPULoongArchVendor;
+struct _virCPULoongArchVendor {
+ char *name;
+};
+
+typedef struct _virCPULoongArchModel virCPULoongArchModel;
+struct _virCPULoongArchModel {
+ char *name;
+ const virCPULoongArchVendor *vendor;
+ virCPULoongArchData data;
+};
+
+typedef struct _virCPULoongArchMap virCPULoongArchMap;
+struct _virCPULoongArchMap {
+ size_t nvendors;
+ virCPULoongArchVendor **vendors;
+ size_t nmodels;
+ virCPULoongArchModel **models;
+};
This CPU driver appears to be directly modeled after the ppc64
driver. I wonder if all the complexity is necessary at this point in
time? Wouldn't it perhaps be better to start with a very bare-bone
CPU driver, modeled after the riscv64 one, and then grow from there
as the demand for more advanced features becomes apparent?
+static int
+virCPULoongArchGetHostPRID(void)
+{
+ return 0x14c010;
+}
Hardcoding the host CPU's PRID...
+static int
+virCPULoongArchGetHost(virCPUDef *cpu,
+ virDomainCapsCPUModels *models)
+{
+ virCPUData *cpuData = NULL;
+ virCPULoongArchData *data;
+ int ret = -1;
+
+ if (!(cpuData = virCPUDataNew(archs[0])))
+ goto cleanup;
+
+ data = &cpuData->data.loongarch;
+ data->prid = g_new0(virCPULoongArchPrid, 1);
+ if (!data->prid)
+ goto cleanup;
+
+
+ data->len = 1;
+
+ data->prid[0].value = virCPULoongArchGetHostPRID();
+ data->prid[0].mask = 0xffff00ul;
... and corresponding mask is definitely not acceptable. You'll need
to implement a function that fetches the value dynamically by using
whatever mechanism is appropriate, and of course ensure that such
code is only ever run on a loongarch64 host.
But again, do we really need that complexity right now? The riscv64
driver doesn't have any of that and is usable for many purposes.
+static virCPUDef *
+virCPULoongArchDriverBaseline(virCPUDef **cpus,
+ unsigned int ncpus,
+ virDomainCapsCPUModels *models ATTRIBUTE_UNUSED,
+ const char **features ATTRIBUTE_UNUSED,
+ bool migratable ATTRIBUTE_UNUSED)
The function arguments are not aligned properly here. There are
several other instances of this. Please make sure that things are
aligned correctly throughout.
diff --git a/src/cpu/meson.build b/src/cpu/meson.build
index 55396903b9..254d6b4545 100644
--- a/src/cpu/meson.build
+++ b/src/cpu/meson.build
@@ -6,6 +6,7 @@ cpu_sources = [
'cpu_riscv64.c',
'cpu_s390.c',
'cpu_x86.c',
+ 'cpu_loongarch.c'
]
This is another list that needs to remain sorted...
+++ b/src/util/virarch.h
@@ -69,6 +69,8 @@ typedef enum {
VIR_ARCH_XTENSA, /* XTensa 32 LE
https://en.wikipedia.org/wiki/Xtensa#Processor_Cores */
VIR_ARCH_XTENSAEB, /* XTensa 32 BE
https://en.wikipedia.org/wiki/Xtensa#Processor_Cores */
+ VIR_ARCH_LOONGARCH64, /* LoongArch 64 LE */
+
VIR_ARCH_LAST,
} virArch;
... as is this one and those that are derived from it, including
preferredMachines.
--
Andrea Bolognani / Red Hat / Virtualization
2:38 p.m.
New subject: [libvirt PATCH 1/5] Add loongarch cpu support
Hi Andrea:
On Thu, Dec 14, 2023 at 02:08:45PM +0800, xianglai li wrote:
> From: lixianglai <lixianglai(a)loongson.cn > Add loongarch cpu support, Define new cpu type
'loongarch64'
> and implement it's driver functions.
> Signed-off-by: lixianglai <lixianglai(a)loongson.cn We usually prefer the full name to be used both for git
authorship
and DCO purposes. I believe this would be "Xianglai Li" in your case.
Ok, I'll correct it in the next version :)
> ---
> po/POTFILES | 1 +
> src/conf/schemas/basictypes.rng | 1 +
> src/cpu/cpu.c | 2 +
> src/cpu/cpu.h | 2 +
> src/cpu/cpu_loongarch.c | 742 ++++++++++++++++++++++++++++++++
> src/cpu/cpu_loongarch.h | 25 ++
> src/cpu/cpu_loongarch_data.h | 37 ++
> src/cpu/meson.build | 1 +
> src/qemu/qemu_capabilities.c | 1 +
> src/qemu/qemu_domain.c | 4 +
> src/util/virarch.c | 2 +
> src/util/virarch.h | 4 +
> 12 files changed, 822 insertions(+)
> create mode 100644 src/cpu/cpu_loongarch.c
> create mode 100644 src/cpu/cpu_loongarch.h
> create mode 100644 src/cpu/cpu_loongarch_data.h
This patch breaks the test suite:
$ make -C .../libvirt/build/build-aux sc_preprocessor_indentation
make: Entering directory '.../libvirt/build/build-aux'
cppi: .../libvirt/src/cpu/cpu_loongarch.h: line 23: not properly indented
cppi: .../libvirt/src/cpu/cpu_loongarch_data.h: line 23: not properly indented
cppi: .../libvirt/src/cpu/cpu_loongarch_data.h: line 31: not properly indented
incorrect preprocessor indentation
make: *** [.../libvirt/build-aux/syntax-check.mk:500:
sc_preprocessor_indentation] Error 1
make: Leaving directory '.../libvirt/build/build-aux'
Should be an easy enough fix.
Please make sure that 'meson test' runs successfully after every
single patch in the series, and that you have optional test tools
such as cppi installed.
Ok, I think it is because I did not install cppi that the problem was
not detected during 'meson test'.
I will install cppi and conduct 'meson test' again for each patch.
> +++ b/src/conf/schemas/basictypes.rng
> @@ -470,6 +470,7 @@
> <value>x86_64</value >
<value>xtensa</value >
<value>xtensaeb</value > +
<value>loongarch64</value This list is sorted alphabetically;
please ensure that it remains
that way after your changes. Not all lists in libvirt are sorted
alphabetically, but generally speaking if you see one that is you
should keep it that way.
Ok, I'll correct it in the next version.
> +++ b/src/cpu/cpu_loongarch.c
> @@ -0,0 +1,742 @@
> +static const virArch archs[] = { VIR_ARCH_LOONGARCH64 };
> +
> +typedef struct _virCPULoongArchVendor virCPULoongArchVendor;
> +struct _virCPULoongArchVendor {
> + char *name;
> +};
> +
> +typedef struct _virCPULoongArchModel virCPULoongArchModel;
> +struct _virCPULoongArchModel {
> + char *name;
> + const virCPULoongArchVendor *vendor;
> + virCPULoongArchData data;
> +};
> +
> +typedef struct _virCPULoongArchMap virCPULoongArchMap;
> +struct _virCPULoongArchMap {
> + size_t nvendors;
> + virCPULoongArchVendor **vendors;
> + size_t nmodels;
> + virCPULoongArchModel **models;
> +};
This CPU driver appears to be directly modeled after the ppc64
driver. I wonder if all the complexity is necessary at this point in
time? Wouldn't it perhaps be better to start with a very bare-bone
CPU driver, modeled after the riscv64 one, and then grow from there
as the demand for more advanced features becomes apparent?
Well, I think I will try to refer to riscv64 for cpu driver
implementation in the next version.
> +static int
> +virCPULoongArchGetHostPRID(void)
> +{
> + return 0x14c010;
> +}
Hardcoding the host CPU's PRID...
> +static int
> +virCPULoongArchGetHost(virCPUDef *cpu,
> + virDomainCapsCPUModels *models)
> +{
> + virCPUData *cpuData = NULL;
> + virCPULoongArchData *data;
> + int ret = -1;
> +
> + if (!(cpuData = virCPUDataNew(archs[0])))
> + goto cleanup;
> +
> + data = &cpuData->data.loongarch;
> + data->prid = g_new0(virCPULoongArchPrid, 1);
> + if (!data->prid)
> + goto cleanup;
> +
> +
> + data->len = 1;
> +
> + data->prid[0].value = virCPULoongArchGetHostPRID();
> + data->prid[0].mask = 0xffff00ul;
... and corresponding mask is definitely not acceptable. You'll need
to implement a function that fetches the value dynamically by using
whatever mechanism is appropriate, and of course ensure that such
code is only ever run on a loongarch64 host.
But again, do we really need that complexity right now? The riscv64
driver doesn't have any of that and is usable for many purposes.
Okay, so the hard coding here is a little bit inappropriate, and I feel
like I can do without the complexity,
I'm not sure, but I can try to simplify this.
> +static virCPUDef *
> +virCPULoongArchDriverBaseline(virCPUDef **cpus,
> + unsigned int ncpus,
> + virDomainCapsCPUModels *models ATTRIBUTE_UNUSED,
> + const char **features ATTRIBUTE_UNUSED,
> + bool migratable ATTRIBUTE_UNUSED)
The function arguments are not aligned properly here. There are
several other instances of this. Please make sure that things are
aligned correctly throughout.
Ok, I will do a code check according to the suggestion.
> diff --git a/src/cpu/meson.build b/src/cpu/meson.build
> index 55396903b9..254d6b4545 100644
> --- a/src/cpu/meson.build
> +++ b/src/cpu/meson.build
> @@ -6,6 +6,7 @@ cpu_sources = [
> 'cpu_riscv64.c',
> 'cpu_s390.c',
> 'cpu_x86.c',
> + 'cpu_loongarch.c'
> ]
This is another list that needs to remain sorted...
Ok, I'll fix it in the next version.
> +++ b/src/util/virarch.h
> @@ -69,6 +69,8 @@ typedef enum {
> VIR_ARCH_XTENSA, /* XTensa 32 LE
https://en.wikipedia.org/wiki/Xtensa#Processor_Cores */
> VIR_ARCH_XTENSAEB, /* XTensa 32 BE
https://en.wikipedia.org/wiki/Xtensa#Processor_Cores */
> + VIR_ARCH_LOONGARCH64, /* LoongArch 64 LE */
> +
> VIR_ARCH_LAST,
> } virArch;
... as is this one and those that are derived from it, including
preferredMachines.
Ok, I'll fix it in the next version.
Thanks,
Xianglai.
2:08 p.m.
New subject: [libvirt PATCH 2/5] Add loongarch cpu model and vendor info
From: lixianglai <lixianglai(a)loongson.cn>
Define loongarch cpu model type and vendor id in
cpu_map loongarch xml.
Signed-off-by: lixianglai <lixianglai(a)loongson.cn>
---
src/cpu_map/index.xml | 5 +++++
src/cpu_map/loongarch_la464.xml | 6 ++++++
src/cpu_map/loongarch_vendors.xml | 3 +++
src/cpu_map/meson.build | 2 ++
4 files changed, 16 insertions(+)
create mode 100644 src/cpu_map/loongarch_la464.xml
create mode 100644 src/cpu_map/loongarch_vendors.xml
diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml
index d2c5af5797..9cfcd1a9c0 100644
--- a/src/cpu_map/index.xml
+++ b/src/cpu_map/index.xml
@@ -119,4 +119,9 @@
<include filename='arm_FT-2000plus.xml'/>
<include filename='arm_Tengyun-S2500.xml'/>
</arch>
+
+ <arch name='loongarch64'>
+ <include filename="loongarch_vendors.xml"/>
+ <include filename="loongarch_la464.xml"/>
+ </arch>
</cpus>
diff --git a/src/cpu_map/loongarch_la464.xml b/src/cpu_map/loongarch_la464.xml
new file mode 100644
index 0000000000..1029e39681
--- /dev/null
+++ b/src/cpu_map/loongarch_la464.xml
@@ -0,0 +1,6 @@
+<cpus>
+ <model name='la464'>
+ <vendor name='Loongson'/>
+ <prid value='0x14c010' mask='0xfffff0'/>
+ </model>
+</cpus>
diff --git a/src/cpu_map/loongarch_vendors.xml b/src/cpu_map/loongarch_vendors.xml
new file mode 100644
index 0000000000..c744654617
--- /dev/null
+++ b/src/cpu_map/loongarch_vendors.xml
@@ -0,0 +1,3 @@
+<cpus>
+ <vendor name='Loongson'/>
+</cpus>
diff --git a/src/cpu_map/meson.build b/src/cpu_map/meson.build
index ae5293e85f..4ea63188df 100644
--- a/src/cpu_map/meson.build
+++ b/src/cpu_map/meson.build
@@ -84,6 +84,8 @@ cpumap_data = [
'x86_vendors.xml',
'x86_Westmere-IBRS.xml',
'x86_Westmere.xml',
+ 'loongarch_vendors.xml',
+ 'loongarch_la464.xml',
]
install_data(cpumap_data, install_dir: pkgdatadir / 'cpu_map')
--
2.27.0
2:08 p.m.
New subject: [libvirt PATCH 3/5] Config some capabilities for loongarch virt machine
From: lixianglai <lixianglai(a)loongson.cn>
Config some capabilities for loongarch virt machine such as
PCI multi bus.
Signed-off-by: lixianglai <lixianglai(a)loongson.cn>
---
src/qemu/qemu_capabilities.c | 5 ++++
src/qemu/qemu_domain.c | 28 +++++++++++++++++
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_domain_address.c | 55 ++++++++++++++++++++++++++++++++++
src/qemu/qemu_validate.c | 2 +-
5 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 118d3429c3..eb84c9da7d 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2080,6 +2080,11 @@ bool virQEMUCapsHasPCIMultiBus(const virDomainDef *def)
return true;
}
+ /* loongarch64 support PCI-multibus on all machine types
+ * since forever */
+ if (ARCH_IS_LOONGARCH(def->os.arch))
+ return true;
+
return false;
}
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 00e38950b6..a8f04155a3 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5635,6 +5635,11 @@ qemuDomainControllerDefPostParse(virDomainControllerDef *cont,
cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_QEMU_XHCI;
else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
+ } else if (ARCH_IS_LOONGARCH(def->os.arch)) {
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_QEMU_XHCI))
+ cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_QEMU_XHCI;
+ else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
+ cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
}
}
/* forbid usb model 'qusb1' and 'qusb2' in this kind of
hyperviosr */
@@ -8924,6 +8929,22 @@ qemuDomainMachineIsPSeries(const char *machine,
}
+static bool
+qemuDomainMachineIsLoongson(const char *machine,
+ const virArch arch)
+{
+ if (!ARCH_IS_LOONGARCH(arch))
+ return false;
+
+ if (STREQ(machine, "virt") ||
+ STRPREFIX(machine, "virt-")) {
+ return true;
+ }
+
+ return false;
+}
+
+
static bool
qemuDomainMachineIsMipsMalta(const char *machine,
const virArch arch)
@@ -9017,6 +9038,13 @@ qemuDomainIsMipsMalta(const virDomainDef *def)
}
+bool
+qemuDomainIsLoongson(const virDomainDef *def)
+{
+ return qemuDomainMachineIsLoongson(def->os.machine, def->os.arch);
+}
+
+
bool
qemuDomainHasPCIRoot(const virDomainDef *def)
{
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index 1e56e50672..1bdbb9c549 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -827,6 +827,7 @@ bool qemuDomainIsS390CCW(const virDomainDef *def);
bool qemuDomainIsARMVirt(const virDomainDef *def);
bool qemuDomainIsRISCVVirt(const virDomainDef *def);
bool qemuDomainIsPSeries(const virDomainDef *def);
+bool qemuDomainIsLoongson(const virDomainDef *def);
bool qemuDomainIsMipsMalta(const virDomainDef *def);
bool qemuDomainHasPCIRoot(const virDomainDef *def);
bool qemuDomainHasPCIeRoot(const virDomainDef *def);
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 099778b2a8..2a37853d56 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -2079,6 +2079,56 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDef *def,
}
+static int
+qemuDomainValidateDevicePCISlotsLoongson(virDomainDef *def,
+ virDomainPCIAddressSet *addrs)
+{
+ virPCIDeviceAddress tmp_addr;
+ g_autofree char *addrStr = NULL;
+ virDomainPCIConnectFlags flags = VIR_PCI_CONNECT_TYPE_PCI_DEVICE;
+
+ if (addrs->nbuses) {
+ memset(&tmp_addr, 0, sizeof(tmp_addr));
+ tmp_addr.slot = 1;
+ /* pci-ohci at 00:01.0 */
+ if (virDomainPCIAddressReserveAddr(addrs, &tmp_addr, flags, 0) < 0)
+ return -1;
+ }
+
+ if (def->nvideos > 0 &&
+ def->videos[0]->type != VIR_DOMAIN_VIDEO_TYPE_NONE &&
+ def->videos[0]->type != VIR_DOMAIN_VIDEO_TYPE_RAMFB) {
+ /* reserve slot 2 for vga device */
+ virDomainVideoDef *primaryVideo = def->videos[0];
+
+ if (virDeviceInfoPCIAddressIsWanted(&primaryVideo->info)) {
+ memset(&tmp_addr, 0, sizeof(tmp_addr));
+ tmp_addr.slot = 2;
+
+ if (!(addrStr = virPCIDeviceAddressAsString(&tmp_addr)))
+ return -1;
+ if (!virDomainPCIAddressValidate(addrs, &tmp_addr,
+ addrStr, flags, true))
+ return -1;
+
+ if (virDomainPCIAddressSlotInUse(addrs, &tmp_addr)) {
+ if (qemuDomainPCIAddressReserveNextAddr(addrs,
+ &primaryVideo->info) <
0) {
+ return -1;
+ }
+ } else {
+ if (virDomainPCIAddressReserveAddr(addrs, &tmp_addr, flags, 0) <
0)
+ return -1;
+ primaryVideo->info.addr.pci = tmp_addr;
+ primaryVideo->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
+ }
+ }
+ }
+
+ return 0;
+}
+
+
static int
qemuDomainValidateDevicePCISlotsChipsets(virDomainDef *def,
virDomainPCIAddressSet *addrs)
@@ -2093,6 +2143,11 @@ qemuDomainValidateDevicePCISlotsChipsets(virDomainDef *def,
return -1;
}
+ if (qemuDomainIsLoongson(def) &&
+ qemuDomainValidateDevicePCISlotsLoongson(def, addrs) < 0) {
+ return -1;
+ }
+
return 0;
}
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index e475ad035e..498e76b1e7 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -100,7 +100,7 @@ qemuValidateDomainDefFeatures(const virDomainDef *def,
switch ((virDomainFeature) i) {
case VIR_DOMAIN_FEATURE_IOAPIC:
if (def->features[i] != VIR_DOMAIN_IOAPIC_NONE) {
- if (!ARCH_IS_X86(def->os.arch)) {
+ if (!ARCH_IS_X86(def->os.arch) &&
!ARCH_IS_LOONGARCH(def->os.arch)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("The '%1$s' feature is not supported
for architecture '%2$s' or machine type '%3$s'"),
featureName,
--
2.27.0
1:56 a.m.
New subject: [libvirt PATCH 3/5] Config some capabilities for loongarch virt machine
On Thu, Dec 14, 2023 at 02:08:47PM +0800, xianglai li wrote:
+++ b/src/qemu/qemu_domain.c
@@ -5635,6 +5635,11 @@ qemuDomainControllerDefPostParse(virDomainControllerDef *cont,
cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_QEMU_XHCI;
else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
+ } else if (ARCH_IS_LOONGARCH(def->os.arch)) {
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_QEMU_XHCI))
+ cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_QEMU_XHCI;
+ else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
+ cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
}
I don't think you need to take into account the nec-xhci model for
loongarch. aarch64 needs it because qemu-xhci didn't exist when that
architecture was introduced, but that's not the case here so we can
keep things simpler.
I'm surprised that this code doesn't have handling for riscv64. Not
your problem, but likely an oversight that should be addressed.
+static bool
+qemuDomainMachineIsLoongson(const char *machine,
+ const virArch arch)
The appropriate name for this function would be
qemuDomainMachineIsLoongArchVirt, to match the existing Arm and
RISC-V equivalents.
+bool
+qemuDomainIsLoongson(const virDomainDef *def)
+{
Same here.
+++ b/src/qemu/qemu_domain_address.c
@@ -2093,6 +2143,11 @@ qemuDomainValidateDevicePCISlotsChipsets(virDomainDef *def,
return -1;
}
+ if (qemuDomainIsLoongson(def) &&
+ qemuDomainValidateDevicePCISlotsLoongson(def, addrs) < 0) {
+ return -1;
+ }
The existing qemuDomainValidateDevicePCISlots* functions are intended
to ensure that certain devices, that historically have been assigned
to specific PCI slots by QEMU, always show up at those addresses.
We haven't needed anything like that for non-x86 architectures so
far, and I believe that loongarch doesn't need it either.
+++ b/src/qemu/qemu_validate.c
@@ -100,7 +100,7 @@ qemuValidateDomainDefFeatures(const virDomainDef *def,
switch ((virDomainFeature) i) {
case VIR_DOMAIN_FEATURE_IOAPIC:
if (def->features[i] != VIR_DOMAIN_IOAPIC_NONE) {
- if (!ARCH_IS_X86(def->os.arch)) {
+ if (!ARCH_IS_X86(def->os.arch) &&
!ARCH_IS_LOONGARCH(def->os.arch)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("The '%1$s' feature is not supported
for architecture '%2$s' or machine type '%3$s'"),
featureName,
So does loongarch actually have ioapic support? Just making sure. I'm
surprised because apparently no other non-x86 architecture supports
it...
--
Andrea Bolognani / Red Hat / Virtualization
11:52 a.m.
New subject: [libvirt PATCH 3/5] Config some capabilities for loongarch virt
machine
Hi Andrea :
On Thu, Dec 14, 2023 at 02:08:47PM +0800, xianglai li wrote:
> +++ b/src/qemu/qemu_domain.c
> @@ -5635,6 +5635,11 @@ qemuDomainControllerDefPostParse(virDomainControllerDef
*cont,
> cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_QEMU_XHCI;
> else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
> cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
> + } else if (ARCH_IS_LOONGARCH(def->os.arch)) {
> + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_QEMU_XHCI))
> + cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_QEMU_XHCI;
> + else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
> + cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
> }
I don't think you need to take into account the nec-xhci model for
loongarch. aarch64 needs it because qemu-xhci didn't exist when that
architecture was introduced, but that's not the case here so we can
keep things simpler.
I'm surprised that this code doesn't have handling for riscv64. Not
your problem, but likely an oversight that should be addressed.
Ok, I'll remove nec-xhci in the next version.
> +static bool
> +qemuDomainMachineIsLoongson(const char *machine,
> + const virArch arch)
The appropriate name for this function would be
qemuDomainMachineIsLoongArchVirt, to match the existing Arm and
RISC-V equivalents.
Ok, I'll correct that in the next version.
> +bool
> +qemuDomainIsLoongson(const virDomainDef *def)
> +{
Same here.
Ok, I'll correct that in the next version.
> +++ b/src/qemu/qemu_domain_address.c
> @@ -2093,6 +2143,11 @@ qemuDomainValidateDevicePCISlotsChipsets(virDomainDef *def,
> return -1;
> }
> + if (qemuDomainIsLoongson(def) &&
> + qemuDomainValidateDevicePCISlotsLoongson(def, addrs) < 0) {
> + return -1;
> + }
The existing qemuDomainValidateDevicePCISlots* functions are intended
to ensure that certain devices, that historically have been assigned
to specific PCI slots by QEMU, always show up at those addresses.
We haven't needed anything like that for non-x86 architectures so
far, and I believe that loongarch doesn't need it either.
Ok, I'll correct that in the next version.
> +++ b/src/qemu/qemu_validate.c
> @@ -100,7 +100,7 @@ qemuValidateDomainDefFeatures(const virDomainDef *def,
> switch ((virDomainFeature) i) {
> case VIR_DOMAIN_FEATURE_IOAPIC:
> if (def->features[i] != VIR_DOMAIN_IOAPIC_NONE) {
> - if (!ARCH_IS_X86(def->os.arch)) {
> + if (!ARCH_IS_X86(def->os.arch) &&
!ARCH_IS_LOONGARCH(def->os.arch)) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> _("The '%1$s' feature is not
supported for architecture '%2$s' or machine type '%3$s'"),
> featureName,
So does loongarch actually have ioapic support? Just making sure. I'm
surprised because apparently no other non-x86 architecture supports
it...
Yes, loongarch does have IOAPIC, but this feature has no effect on
loongarch at this stage, I will cut it first to simplify the committed code.
In addition, I have a question, if I understand correctly, the IOAPIC
here should be the device interrupt controller, which is located in the
bridge chip,
it is called IOAPIC under x86, PCH_PIC under loongarch, and GIC under arm.
The kernel_irqchip attribute of the machine parameter in qemu
corresponding to the function VIR_DOMAIN_FEATURE_IOAPIC determines
whether the device interrupt controller is simulated in qemu or kvm. So
arm also has such a need, but why doesn't arm add?
11:08 p.m.
New subject: [libvirt PATCH 3/5] Config some capabilities for loongarch
virt machine
On Tue, Dec 19, 2023 at 11:52:03AM +0800, lixianglai wrote:
> So does loongarch actually have ioapic support? Just making
sure. I'm
> surprised because apparently no other non-x86 architecture supports
> it...
Yes, loongarch does have IOAPIC, but this feature has no effect on loongarch
at this stage, I will cut it first to simplify the committed code.
In addition, I have a question, if I understand correctly, the IOAPIC here
should be the device interrupt controller, which is located in the bridge
chip,
it is called IOAPIC under x86, PCH_PIC under loongarch, and GIC under arm.
The kernel_irqchip attribute of the machine parameter in qemu corresponding
to the function VIR_DOMAIN_FEATURE_IOAPIC determines
whether the device interrupt controller is simulated in qemu or kvm. So arm
also has such a need, but why doesn't arm add?
Okay, so x86's IOAPIC is controlled by the <ioapic> element, while
Arm's GIC uses the <gic> element. By that logic, loongarch should
probably introduce a <phc-pic> element.
It's a bit silly that we need a separate element per architecture,
especially considering that most of the time we just want to control
the kernel_irqchip flag. Case in point, as you noticed Arm doesn't
expose the ability to configure that at the moment.
On the other hand, additional arch-features might show up in the
future, at which point the separate element would start making sense.
See GIC for an example.
Overall, if you don't have a pressing need to expose the ability to
control the kernel_irqchip flag I would just avoid doing anything
about it now and leave the decision for another day and, possibly,
person :)
--
Andrea Bolognani / Red Hat / Virtualization
11:13 a.m.
New subject: [libvirt PATCH 3/5] Config some capabilities for loongarch virt
machine
Hi Andrea:
On Tue, Dec 19, 2023 at 11:52:03AM +0800, lixianglai wrote:
>> So does loongarch actually have ioapic support? Just making sure. I'm
>> surprised because apparently no other non-x86 architecture supports
>> it...
> Yes, loongarch does have IOAPIC, but this feature has no effect on loongarch
> at this stage, I will cut it first to simplify the committed code.
>
> In addition, I have a question, if I understand correctly, the IOAPIC here
> should be the device interrupt controller, which is located in the bridge
> chip,
>
> it is called IOAPIC under x86, PCH_PIC under loongarch, and GIC under arm.
>
> The kernel_irqchip attribute of the machine parameter in qemu corresponding
> to the function VIR_DOMAIN_FEATURE_IOAPIC determines
>
> whether the device interrupt controller is simulated in qemu or kvm. So arm
> also has such a need, but why doesn't arm add?
Okay, so x86's IOAPIC is controlled by the <ioapic> element, while
Arm's GIC uses the <gic> element. By that logic, loongarch should
probably introduce a <phc-pic> element.
It's a bit silly that we need a separate element per architecture,
especially considering that most of the time we just want to control
the kernel_irqchip flag. Case in point, as you noticed Arm doesn't
expose the ability to configure that at the moment.
On the other hand, additional arch-features might show up in the
future, at which point the separate element would start making sense.
See GIC for an example.
Overall, if you don't have a pressing need to expose the ability to
control the kernel_irqchip flag I would just avoid doing anything
about it now and leave the decision for another day and, possibly,
person :)
Ok, I see. Thank you very much!
Thanks,
Xianglai.
11:56 a.m.
New subject: [libvirt PATCH 3/5] Config some capabilities for loongarch virt
machine
Hi Andrea :
On Thu, Dec 14, 2023 at 02:08:47PM +0800, xianglai li wrote:
> +++ b/src/qemu/qemu_domain.c
> @@ -5635,6 +5635,11 @@
> qemuDomainControllerDefPostParse(virDomainControllerDef *cont,
> cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_QEMU_XHCI;
> else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
> cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
> + } else if (ARCH_IS_LOONGARCH(def->os.arch)) {
> + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_QEMU_XHCI))
> + cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_QEMU_XHCI;
> + else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
> + cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
> }
I don't think you need to take into account the nec-xhci model for
loongarch. aarch64 needs it because qemu-xhci didn't exist when that
architecture was introduced, but that's not the case here so we can
keep things simpler.
I'm surprised that this code doesn't have handling for riscv64. Not
your problem, but likely an oversight that should be addressed.
Ok, I'll remove nec-xhci in the next version.
> +static bool
> +qemuDomainMachineIsLoongson(const char *machine,
> + const virArch arch)
The appropriate name for this function would be
qemuDomainMachineIsLoongArchVirt, to match the existing Arm and
RISC-V equivalents.
Ok, I'll correct that in the next version.
> +bool
> +qemuDomainIsLoongson(const virDomainDef *def)
> +{
Same here.
Ok, I'll correct that in the next version.
> +++ b/src/qemu/qemu_domain_address.c
> @@ -2093,6 +2143,11 @@
> qemuDomainValidateDevicePCISlotsChipsets(virDomainDef *def,
> return -1;
> }
> + if (qemuDomainIsLoongson(def) &&
> + qemuDomainValidateDevicePCISlotsLoongson(def, addrs) < 0) {
> + return -1;
> + }
The existing qemuDomainValidateDevicePCISlots* functions are intended
to ensure that certain devices, that historically have been assigned
to specific PCI slots by QEMU, always show up at those addresses.
We haven't needed anything like that for non-x86 architectures so
far, and I believe that loongarch doesn't need it either.
Ok, I'll correct that in the next version.
> +++ b/src/qemu/qemu_validate.c
> @@ -100,7 +100,7 @@ qemuValidateDomainDefFeatures(const virDomainDef
> *def,
> switch ((virDomainFeature) i) {
> case VIR_DOMAIN_FEATURE_IOAPIC:
> if (def->features[i] != VIR_DOMAIN_IOAPIC_NONE) {
> - if (!ARCH_IS_X86(def->os.arch)) {
> + if (!ARCH_IS_X86(def->os.arch) && !ARCH_IS_LOONGARCH(def->os.arch))
{
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> _("The '%1$s' feature is not supported for architecture '%2$s'
or
> machine type '%3$s'"),
> featureName,
So does loongarch actually have ioapic support? Just making sure. I'm
surprised because apparently no other non-x86 architecture supports
it...
Yes, loongarch does have IOAPIC, but this feature has no effect on
loongarch at this stage, I will cut it first to simplify the committed code.
In addition, I have a question, if I understand correctly, the IOAPIC
here should be the device interrupt controller, which is located in the
bridge chip,
it is called IOAPIC under x86, PCH_PIC under loongarch, and GIC under arm.
The kernel_irqchip attribute of the machine parameter in qemu
corresponding to the function VIR_DOMAIN_FEATURE_IOAPIC determines
whether the device interrupt controller is simulated in qemu or kvm. So
arm also has such a need, but why doesn't arm add?
Thanks,
Xianglai.
2:08 p.m.
New subject: [libvirt PATCH 4/5] Implement the method of getting host info for loongarch
From: lixianglai <lixianglai(a)loongson.cn>
Implement method for loongarch to get host info, such as
cpu frequency, system info, etc.
Signed-off-by: lixianglai <lixianglai(a)loongson.cn>
---
src/util/virarch.c | 2 ++
src/util/virhostcpu.c | 4 ++--
src/util/virsysinfo.c | 5 +++--
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/util/virarch.c b/src/util/virarch.c
index 289bd80d90..8107279fb8 100644
--- a/src/util/virarch.c
+++ b/src/util/virarch.c
@@ -224,6 +224,8 @@ virArch virArchFromHost(void)
arch = VIR_ARCH_X86_64;
} else if (STREQ(ut.machine, "arm64")) {
arch = VIR_ARCH_AARCH64;
+ } else if (STREQ(ut.machine, "loongarch64")) {
+ arch = VIR_ARCH_LOONGARCH64;
} else {
/* Otherwise assume the canonical name */
if ((arch = virArchFromString(ut.machine)) == VIR_ARCH_NONE) {
diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c
index 4027547e1e..15e97151d6 100644
--- a/src/util/virhostcpu.c
+++ b/src/util/virhostcpu.c
@@ -544,7 +544,7 @@ virHostCPUParseFrequency(FILE *cpuinfo,
char line[1024];
/* No sensible way to retrieve CPU frequency */
- if (ARCH_IS_ARM(arch))
+ if (ARCH_IS_ARM(arch) || ARCH_IS_LOONGARCH(arch))
return 0;
if (ARCH_IS_X86(arch))
@@ -579,7 +579,7 @@ virHostCPUParsePhysAddrSize(FILE *cpuinfo, unsigned int *addrsz)
char *str;
char *endptr;
- if (!(str = STRSKIP(line, "address sizes")))
+ if (!(str = STRCASESKIP(line, "address sizes")))
continue;
/* Skip the colon. */
diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c
index 36a861c53f..3a09497725 100644
--- a/src/util/virsysinfo.c
+++ b/src/util/virsysinfo.c
@@ -1241,14 +1241,15 @@ virSysinfoRead(void)
{
#if defined(__powerpc__)
return virSysinfoReadPPC();
-#elif defined(__arm__) || defined(__aarch64__)
+#elif defined(__arm__) || defined(__aarch64__) || defined(__loongarch__)
return virSysinfoReadARM();
#elif defined(__s390__) || defined(__s390x__)
return virSysinfoReadS390();
#elif !defined(WIN32) && \
(defined(__x86_64__) || \
defined(__i386__) || \
- defined(__amd64__))
+ defined(__amd64__) || \
+ defined(__loongarch__))
return virSysinfoReadDMI();
#else /* WIN32 || not supported arch */
/*
--
2.27.0
2:01 a.m.
New subject: [libvirt PATCH 4/5] Implement the method of getting host info for loongarch
On Thu, Dec 14, 2023 at 02:08:48PM +0800, xianglai li wrote:
+++ b/src/util/virhostcpu.c
@@ -579,7 +579,7 @@ virHostCPUParsePhysAddrSize(FILE *cpuinfo, unsigned int *addrsz)
char *str;
char *endptr;
- if (!(str = STRSKIP(line, "address sizes")))
+ if (!(str = STRCASESKIP(line, "address sizes")))
continue;
So is the case different on loongarch than it is on other
architectures? Weird.
+++ b/src/util/virsysinfo.c
@@ -1241,14 +1241,15 @@ virSysinfoRead(void)
{
#if defined(__powerpc__)
return virSysinfoReadPPC();
-#elif defined(__arm__) || defined(__aarch64__)
+#elif defined(__arm__) || defined(__aarch64__) || defined(__loongarch__)
return virSysinfoReadARM();
This is definitely not right: we shouldn't be calling the
Arm-specific function on loongarch.
#elif defined(__s390__) || defined(__s390x__)
return virSysinfoReadS390();
#elif !defined(WIN32) && \
(defined(__x86_64__) || \
defined(__i386__) || \
- defined(__amd64__))
+ defined(__amd64__) || \
+ defined(__loongarch__))
return virSysinfoReadDMI();
Does loongarch actually have DMI support?
--
Andrea Bolognani / Red Hat / Virtualization
5:23 p.m.
New subject: [libvirt PATCH 4/5] Implement the method of getting host info for
loongarch
Hi Andrea:
On Thu, Dec 14, 2023 at 02:08:48PM +0800, xianglai li wrote:
> +++ b/src/util/virhostcpu.c
> @@ -579,7 +579,7 @@ virHostCPUParsePhysAddrSize(FILE *cpuinfo, unsigned int *addrsz)
> char *str;
> char *endptr;
>
> - if (!(str = STRSKIP(line, "address sizes")))
> + if (!(str = STRCASESKIP(line, "address sizes")))
> continue;
So is the case different on loongarch than it is on other
architectures? Weird.
Yes, loongarch and x86 do have some similarities and differences in the
cpu Address space string, loongarch is "Address Sizes" under X86 is
"address sizes",
arm and other architectures should not have this identifier, At present,
only x86 architecture and sh architecture can enter the process,
other architectures will directly return, and the superior call also
needs to allow the loongarch architecture. I will correct it in the next
version
> +++ b/src/util/virsysinfo.c
> @@ -1241,14 +1241,15 @@ virSysinfoRead(void)
> {
> #if defined(__powerpc__)
> return virSysinfoReadPPC();
> -#elif defined(__arm__) || defined(__aarch64__)
> +#elif defined(__arm__) || defined(__aarch64__) || defined(__loongarch__)
> return virSysinfoReadARM();
This is definitely not right: we shouldn't be calling the
Arm-specific function on loongarch.
Ok, I'll correct that in the next version.
> #elif defined(__s390__) || defined(__s390x__)
> return virSysinfoReadS390();
> #elif !defined(WIN32) && \
> (defined(__x86_64__) || \
> defined(__i386__) || \
> - defined(__amd64__))
> + defined(__amd64__) || \
> + defined(__loongarch__))
> return virSysinfoReadDMI();
Does loongarch actually have DMI support?
Yes, loongarch does support dmi.
Thanks,
Xianglai.
10:18 p.m.
New subject: [libvirt PATCH 4/5] Implement the method of getting host info
for loongarch
On Tue, Dec 19, 2023 at 05:23:36PM +0800, lixianglai wrote:
> On Thu, Dec 14, 2023 at 02:08:48PM +0800, xianglai li wrote:
> > +++ b/src/util/virhostcpu.c
> > @@ -579,7 +579,7 @@ virHostCPUParsePhysAddrSize(FILE *cpuinfo, unsigned int
*addrsz)
> > char *str;
> > char *endptr;
> >
> > - if (!(str = STRSKIP(line, "address sizes")))
> > + if (!(str = STRCASESKIP(line, "address sizes")))
> > continue;
>
> So is the case different on loongarch than it is on other
> architectures? Weird.
Yes, loongarch and x86 do have some similarities and differences in the cpu
Address space string, loongarch is "Address Sizes" under X86 is "address
sizes",
Unfortunate choice on the kernel's part, but not much we can do about
that I guess. The way you handled it is perfectly fine.
arm and other architectures should not have this identifier, At
present,
only x86 architecture and sh architecture can enter the process,
other architectures will directly return, and the superior call also needs
to allow the loongarch architecture. I will correct it in the next version
Good catch! I hadn't even noticed that but it definitely needs to be
addressed.
> > #elif !defined(WIN32) && \
> > (defined(__x86_64__) || \
> > defined(__i386__) || \
> > - defined(__amd64__))
> > + defined(__amd64__) || \
> > + defined(__loongarch__))
> > return virSysinfoReadDMI();
>
> Does loongarch actually have DMI support?
Yes, loongarch does support dmi.
Excellent, just making sure :)
--
Andrea Bolognani / Red Hat / Virtualization
2:08 p.m.
New subject: [libvirt PATCH 5/5] Add bios path for loongarch
From: lixianglai <lixianglai(a)loongson.cn>
Add a default BIOS file name for loongarch.
Signed-off-by: lixianglai <lixianglai(a)loongson.cn>
---
src/qemu/qemu.conf.in | 3 ++-
src/qemu/qemu_conf.c | 3 ++-
src/qemu/test_libvirtd_qemu.aug.in | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in
index 6897e0f760..54c18e31b9 100644
--- a/src/qemu/qemu.conf.in
+++ b/src/qemu/qemu.conf.in
@@ -842,7 +842,8 @@
# "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",
# "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",
# "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd",
-# "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd"
+# "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd",
+#
"/usr/share/qemu/edk2-loongarch64-code.fd:/usr/share/qemu/edk2-loongarch64-vars.fd"
#]
# The backend to use for handling stdout/stderr output from
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 513b5ebb1e..5fe711ee1d 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -93,7 +93,8 @@ VIR_ONCE_GLOBAL_INIT(virQEMUConfig);
"/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd:" \
"/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd:" \
"/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd:" \
- "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd"
+ "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd:" \
+
"/usr/share/qemu/edk2-loongarch64-code.fd:/usr/share/qemu/edk2-loongarch64-vars.fd"
#endif
diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in
index c730df40b0..92f886a968 100644
--- a/src/qemu/test_libvirtd_qemu.aug.in
+++ b/src/qemu/test_libvirtd_qemu.aug.in
@@ -99,6 +99,7 @@ module Test_libvirtd_qemu =
{ "2" =
"/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd" }
{ "3" =
"/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd" }
{ "4" =
"/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd" }
+ { "5" =
"/usr/share/qemu/edk2-loongarch64-code.fd:/usr/share/qemu/edk2-loongarch64-vars.fd"
}
}
{ "stdio_handler" = "logd" }
{ "gluster_debug_level" = "9" }
--
2.27.0
2:11 a.m.
New subject: [libvirt PATCH 5/5] Add bios path for loongarch
On Thu, Dec 14, 2023 at 02:08:49PM +0800, xianglai li wrote:
+++ b/src/qemu/qemu_conf.c
@@ -93,7 +93,8 @@ VIR_ONCE_GLOBAL_INIT(virQEMUConfig);
"/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd:" \
"/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd:" \
"/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd:" \
- "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd"
+ "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd:" \
+
"/usr/share/qemu/edk2-loongarch64-code.fd:/usr/share/qemu/edk2-loongarch64-vars.fd"
#endif
We definitely don't want this :)
The hard-coded CODE:VARS pairs are considered a legacy mechanism at
this point, and we're no longer adding to them. If you try to pass a
custom value at build time, a warning will be raised.
The way firmware is configured these days is through firmware
descriptor files. See src/qemu/qemu_firmware* and tests/qemufirmware*
for additional information, but the short version is that you want
your edk2 package to include something like this:
# /usr/share/qemu/firmware/50-edk2-loongarch64.json
{
"interface-types": [
"uefi"
],
"mapping": {
"device": "flash",
"mode" : "split",
"executable": {
"filename": "/usr/share/edk2/loongarch64/QEMU_CODE.fd",
"format": "raw"
},
"nvram-template": {
"filename": "/usr/share/edk2/loongarch64/QEMU_VARS.fd",
"format": "raw"
}
},
"targets": [
{
"architecture": "loongarch64",
"machines": [
"virt",
"virt-*"
]
}
]
}
Once you have that, libvirt will automatically pick up the correct
firmware when the VM is configured with
<os firmware='efi'>
Same as any other architecture, no custom entries needed.
--
Andrea Bolognani / Red Hat / Virtualization
7:44 p.m.
New subject: [libvirt PATCH 5/5] Add bios path for loongarch
Hi Andrea Bolognani:
On Thu, Dec 14, 2023 at 02:08:49PM +0800, xianglai li wrote:
> +++ b/src/qemu/qemu_conf.c
> @@ -93,7 +93,8 @@ VIR_ONCE_GLOBAL_INIT(virQEMUConfig);
> "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd:" \
> "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd:"
\
> "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd:" \
> - "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd"
> + "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd:"
\
> +
"/usr/share/qemu/edk2-loongarch64-code.fd:/usr/share/qemu/edk2-loongarch64-vars.fd"
> #endif
We definitely don't want this :)
The hard-coded CODE:VARS pairs are considered a legacy mechanism at
this point, and we're no longer adding to them. If you try to pass a
custom value at build time, a warning will be raised.
The way firmware is configured these days is through firmware
descriptor files. See src/qemu/qemu_firmware* and tests/qemufirmware*
for additional information, but the short version is that you want
your edk2 package to include something like this:
# /usr/share/qemu/firmware/50-edk2-loongarch64.json
{
"interface-types": [
"uefi"
],
"mapping": {
"device": "flash",
"mode" : "split",
"executable": {
"filename": "/usr/share/edk2/loongarch64/QEMU_CODE.fd",
"format": "raw"
},
"nvram-template": {
"filename": "/usr/share/edk2/loongarch64/QEMU_VARS.fd",
"format": "raw"
}
},
"targets": [
{
"architecture": "loongarch64",
"machines": [
"virt",
"virt-*"
]
}
]
}
Once you have that, libvirt will automatically pick up the correct
firmware when the VM is configured with
<os firmware='efi'>
Same as any other architecture, no custom entries needed.
Ok, I will remove the custom bios path and then try to add json in the
qemu and edk2 installation packages.
Thanks,
Xianglai.
10:28 p.m.
New subject: [libvirt PATCH 5/5] Add bios path for loongarch
On Tue, Dec 19, 2023 at 07:44:02PM +0800, lixianglai wrote:
> On Thu, Dec 14, 2023 at 02:08:49PM +0800, xianglai li wrote:
> The way firmware is configured these days is through firmware
> descriptor files. See src/qemu/qemu_firmware* and tests/qemufirmware*
> for additional information, but the short version is that you want
> your edk2 package to include something like this:
>
> # /usr/share/qemu/firmware/50-edk2-loongarch64.json
> {
> "interface-types": [
> "uefi"
> ],
> "mapping": {
> "device": "flash",
> "mode" : "split",
> "executable": {
> "filename":
"/usr/share/edk2/loongarch64/QEMU_CODE.fd",
> "format": "raw"
> },
> "nvram-template": {
> "filename":
"/usr/share/edk2/loongarch64/QEMU_VARS.fd",
> "format": "raw"
> }
> },
> "targets": [
> {
> "architecture": "loongarch64",
> "machines": [
> "virt",
> "virt-*"
> ]
> }
> ]
> }
Ok, I will remove the custom bios path and then try to add json in the qemu
and edk2 installation packages.
Note that the JSON descriptor files in tests/qemufirmwaredata/ are
taken directly from the Fedora edk2 package, and in the long run we
want that to be the case for loongarch too, but you don't necessarily
need to wait for the firmware to be packaged in Fedora before
creating libvirt test cases. You can just have a file containing
reasonable-looking values, such as the ones I've shown above, to get
things going, and then we can replace it with the actual one for
Fedora at a later time.
The QEMU package itself doesn't ship any JSON descriptor files.
--
Andrea Bolognani / Red Hat / Virtualization
11:16 a.m.
New subject: [libvirt PATCH 5/5] Add bios path for loongarch
Hi Andrea:
On Tue, Dec 19, 2023 at 07:44:02PM +0800, lixianglai wrote:
>> On Thu, Dec 14, 2023 at 02:08:49PM +0800, xianglai li wrote:
>> The way firmware is configured these days is through firmware
>> descriptor files. See src/qemu/qemu_firmware* and tests/qemufirmware*
>> for additional information, but the short version is that you want
>> your edk2 package to include something like this:
> >> #
/usr/share/qemu/firmware/50-edk2-loongarch64.json
>> {
>> "interface-types": [
>> "uefi"
>> ],
>> "mapping": {
>> "device": "flash",
>> "mode" : "split",
>> "executable": {
>> "filename":
"/usr/share/edk2/loongarch64/QEMU_CODE.fd",
>> "format": "raw"
>> },
>> "nvram-template": {
>> "filename":
"/usr/share/edk2/loongarch64/QEMU_VARS.fd",
>> "format": "raw"
>> }
>> },
>> "targets": [
>> {
>> "architecture": "loongarch64",
>> "machines": [
>> "virt",
>> "virt-*"
>> ]
>> }
>> ]
>> }
> Ok, I will remove the custom bios path and then try to add json in the qemu
> and edk2 installation packages.
Note that the JSON descriptor files in tests/qemufirmwaredata/ are
taken directly from the Fedora edk2 package, and in the long run we
want that to be the case for loongarch too, but you don't necessarily
need to wait for the firmware to be packaged in Fedora before
creating libvirt test cases. You can just have a file containing
reasonable-looking values, such as the ones I've shown above, to get
things going, and then we can replace it with the actual one for
Fedora at a later time.
The QEMU package itself doesn't ship any JSON descriptor files.
Ok, I see. Thank you very much!
Thanks,
Xianglai.
2:55 a.m.
On Thu, Dec 14, 2023 at 02:08:44PM +0800, xianglai li wrote:
Hello, Everyone:
This patch series adds libvirt support for loongarch.Although the bios
path and name has not been officially integrated into qemu and we think
there are still many shortcomings, we try to push a version of patch to
the community according to the opinions of the community, hoping to
listen to everyone's opinions.
Sharing your work earlier rather than later is definitely a good
approach when it comes to open source development, so I appreciate
you doing this :)
loongarch's virtual machine bios is not yet available in qemu,
so you can get it from the following link
https://github.com/loongson/Firmware/tree/main/LoongArchVirtMachine
Great to see that edk2 support has already been mainlined! An
excellent next step would be to get an edk2-loongarch64 package into
the various distros... Please consider working with the maintainers
for edk2 in Fedora to make that happen, as it would significantly
lower the barrier for interested people to get involved.
(Note: You should clone the repository using git instead of
downloading the file via wget or you'll get xml)
We named the bios edk2-loongarch64-code.fd, edk2-loongarch64-vars.fd is used to store
pflash images of non-volatile
variables.After installing qemu-system-loongarch64, you need to manually copy these two
files to the /user/share/qemu
directory.
As I have implicitly pointed out in the comment to one of the
patches, these paths are not correct.
The /usr/share/qemu/ directory is owned by the QEMU package, and
other components should not drop their files in there. The exception
is the /usr/share/qemu/firmware/ directory, which is specifically
designed for interoperation.
The edk2 files should be installed to /usr/share/edk2/loongarch64/,
following the convention established by existing architectures. Once
the directory name already contains architecture information, you can
use shorter and less unique names for the files themselves.
Well, if you have completed the above steps I think you can now
install loongarch virtual machine,
you can install it through the virt-manager graphical interface, or install it through
vrit-install,
here is an example of installing it using virt-install:
virt-install \
--virt-type=qemu \
--name loongarch-test \
--memory 4096 \
--vcpus=4 \
--arch=loongarch64 \
--boot cdrom \
--disk device=cdrom,bus=scsi,path=/root/livecd-fedora-mate-4.loongarch64.iso \
--disk
path=/var/lib/libvirt/images/debian12-loongarch64.qcow2,size=10,format=qcow2,bus=scsi \
--network network=default \
--osinfo archlinux \
--feature acpi=true \
This looks a bit out of place: virt-install should automatically
enable the ACPI feature if it's advertised as available by libvirt.
Please take a look at virQEMUCapsInitGuestFromBinary() and consider
updating it so that ACPI support for loongarch is advertised.
lixianglai (5):
Add loongarch cpu support
Add loongarch cpu model and vendor info
Config some capabilities for loongarch virt machine
Implement the method of getting host info for loongarch
Add bios path for loongarch
The information provided in the cover letter, including pointers to
the various not-yet-upstreamed changes and instructions on how to
test everything, is very much appreciated!
Unfortunately I didn't have enough time to take things for a spin, so
I've limited myself to a relatively quick review.
In addition to the comments that I've provided for the code that is
there, I need to point out what is *not* there: specifically, any
kind of test :)
Before this can be considered for inclusion, we need to have some
test coverage. It doesn't have to be incredibly exhaustive, but at
least the basics need to be addressed. If you look for files that
contain "riscv64" in their names in the tests/ directory you should
get a decent idea of what kind of coverage we will need.
That's all I have for now. I'll talk to you again in 2024 :)
--
Andrea Bolognani / Red Hat / Virtualization
11:40 a.m.
Hi Andrea:
On Thu, Dec 14, 2023 at 02:08:44PM +0800, xianglai li wrote:
> Hello, Everyone:
> This patch series adds libvirt support for loongarch.Although the bios
> path and name has not been officially integrated into qemu and we think
> there are still many shortcomings, we try to push a version of patch to
> the community according to the opinions of the community, hoping to
> listen to everyone's opinions.
Sharing your work earlier rather than later is definitely a good
approach when it comes to open source development, so I appreciate
you doing this :)
Thank you very much for your affirmation and encouragement!
> loongarch's virtual machine bios is not yet available in
qemu, so you can get it from the following link
> https://github.com/loongson/Firmware/tree/main/LoongArchVirtMachine
Great to see that edk2 support has already been mainlined! An
excellent next step would be to get an edk2-loongarch64 package into
the various distros... Please consider working with the maintainers
for edk2 in Fedora to make that happen, as it would significantly
lower the barrier for interested people to get involved.
Yes, we will do that, currently the loongarch code is being moved from
the edk2-platform directory to the edk2 directory,
I think after this work is completed, we will have the edk2 installation
package.
> (Note: You should clone the repository using git instead of
downloading the file via wget or you'll get xml)
> We named the bios edk2-loongarch64-code.fd, edk2-loongarch64-vars.fd is used to store
pflash images of non-volatile
> variables.After installing qemu-system-loongarch64, you need to manually copy these
two files to the /user/share/qemu
> directory.
As I have implicitly pointed out in the comment to one of the
patches, these paths are not correct.
The /usr/share/qemu/ directory is owned by the QEMU package, and
other components should not drop their files in there. The exception
is the /usr/share/qemu/firmware/ directory, which is specifically
designed for interoperation.
The edk2 files should be installed to /usr/share/edk2/loongarch64/,
following the convention established by existing architectures. Once
the directory name already contains architecture information, you can
use shorter and less unique names for the files themselves.
I think edk2-loongarch64-code.fd can be the loongarch bios that comes
with the qemu package,
and then its installation path is /usr/share/qemu which makes sense.
The future separately generated loongarch edk2 installation package
installation path according to your suggestion can be
/usr/share/edk2/loongarch64, named then QEMU_EFI. Fd.
> Well, if you have completed the above steps I think you can now install loongarch
virtual machine,
> you can install it through the virt-manager graphical interface, or install it
through vrit-install,
> here is an example of installing it using virt-install:
>
> virt-install \
> --virt-type=qemu \
> --name loongarch-test \
> --memory 4096 \
> --vcpus=4 \
> --arch=loongarch64 \
> --boot cdrom \
> --disk device=cdrom,bus=scsi,path=/root/livecd-fedora-mate-4.loongarch64.iso \
> --disk
path=/var/lib/libvirt/images/debian12-loongarch64.qcow2,size=10,format=qcow2,bus=scsi \
> --network network=default \
> --osinfo archlinux \
> --feature acpi=true \
This looks a bit out of place: virt-install should automatically
enable the ACPI feature if it's advertised as available by libvirt.
Please take a look at virQEMUCapsInitGuestFromBinary() and consider
updating it so that ACPI support for loongarch is advertised.
Ok, I'll fix that in the next version.
> lixianglai (5):
> Add loongarch cpu support
> Add loongarch cpu model and vendor info
> Config some capabilities for loongarch virt machine
> Implement the method of getting host info for loongarch
> Add bios path for loongarch
The information provided in the cover letter, including pointers to
the various not-yet-upstreamed changes and instructions on how to
test everything, is very much appreciated!
Ok, I will provide more detailed
instructions on changes and testing in
the next version.
Unfortunately I didn't have enough time to take things for a spin, so
I've limited myself to a relatively quick review.
In addition to the comments that I've provided for the code that is
there, I need to point out what is *not* there: specifically, any
kind of test :)
Before this can be considered for inclusion, we need to have some
test coverage. It doesn't have to be incredibly exhaustive, but at
least the basics need to be addressed. If you look for files that
contain "riscv64" in their names in the tests/ directory you should
get a decent idea of what kind of coverage we will need.
Ok, I will refer to the "riscv64" file in the tests directory to add
loongarch64 related test cases.
That's all I have for now. I'll talk to you again in 2024 :)
Ok, thank you very much for taking time out of your busy schedule to
review these patches.
Wish you a merry Christmas in advance.
Thanks!
Xianglai.
10:52 p.m.
On Mon, Dec 18, 2023 at 11:40:03AM +0800, lixianglai wrote:
On Thu, Dec 14, 2023 at 02:08:44PM +0800, xianglai li wrote:
> Great to see that edk2 support has already been mainlined! An
> excellent next step would be to get an edk2-loongarch64 package into
> the various distros... Please consider working with the maintainers
> for edk2 in Fedora to make that happen, as it would significantly
> lower the barrier for interested people to get involved.
Yes, we will do that, currently the loongarch code is being moved from the
edk2-platform directory to the edk2 directory,
I think after this work is completed, we will have the edk2 installation
package.
I'm not very familiar with how the edk2 repository is maintained, but
that sounds like a good plan. Presumably an edk2 release will have to
be tagged as well.
> The /usr/share/qemu/ directory is owned by the QEMU package,
and
> other components should not drop their files in there. The exception
> is the /usr/share/qemu/firmware/ directory, which is specifically
> designed for interoperation.
>
> The edk2 files should be installed to /usr/share/edk2/loongarch64/,
> following the convention established by existing architectures. Once
> the directory name already contains architecture information, you can
> use shorter and less unique names for the files themselves.
I think edk2-loongarch64-code.fd can be the loongarch bios that comes with
the qemu package,
and then its installation path is /usr/share/qemu which makes sense.
Yes, but distro packages usually strip those bits and rely on
firmware packages being installed separately instead.
It's just a minor point. As long as support is still being merged
into the various upstream projects, testing things out is always
going to be messy. It will naturally become smoother over time :)
> The information provided in the cover letter, including pointers
to
> the various not-yet-upstreamed changes and instructions on how to
> test everything, is very much appreciated!
Ok, I will provide more detailed instructions on changes and testing in the
next version.
Personally I think that the information related to testing that
you've provided in the cover letter is quite extensive, so don't feel
that you necessarily need to expand upon it.
--
Andrea Bolognani / Red Hat / Virtualization
11:21 a.m.
Hi Andrea :
On Mon, Dec 18, 2023 at 11:40:03AM +0800, lixianglai wrote:
> On Thu, Dec 14, 2023 at 02:08:44PM +0800, xianglai li wrote:
>> Great to see that edk2 support has already been mainlined! An
>> excellent next step would be to get an edk2-loongarch64 package into
>> the various distros... Please consider working with the maintainers
>> for edk2 in Fedora to make that happen, as it would significantly
>> lower the barrier for interested people to get involved.
> Yes, we will do that, currently the loongarch code is being moved from the
> edk2-platform directory to the edk2 directory,
>
> I think after this work is completed, we will have the edk2 installation
> package.
I'm not very familiar with how the edk2 repository is maintained, but
that sounds like a good plan. Presumably an edk2 release will have to
be tagged as well.
>> The /usr/share/qemu/ directory is owned by the QEMU package, and
>> other components should not drop their files in there. The exception
>> is the /usr/share/qemu/firmware/ directory, which is specifically
>> designed for interoperation.
>>
>> The edk2 files should be installed to /usr/share/edk2/loongarch64/,
>> following the convention established by existing architectures. Once
>> the directory name already contains architecture information, you can
>> use shorter and less unique names for the files themselves.
> I think edk2-loongarch64-code.fd can be the loongarch bios that comes with
> the qemu package,
>
> and then its installation path is /usr/share/qemu which makes sense.
Yes, but distro packages usually strip those bits and rely on
firmware packages being installed separately instead.
It's just a minor point. As long as support is still being merged
into the various upstream projects, testing things out is always
going to be messy. It will naturally become smoother over time :)
Ok, I see. Thank you very much!
>> The information provided in the cover letter, including
pointers to
>> the various not-yet-upstreamed changes and instructions on how to
>> test everything, is very much appreciated!
> Ok, I will provide more detailed instructions on changes and testing in the
> next version.
Personally I think that the information related to testing that
you've provided in the cover letter is quite extensive, so don't feel
that you necessarily need to expand upon it.
Ok, I see. Thank you very much!
Thanks,
Xianglai.
287
days inactive
308
days old
23 comments
3 participants
participants (3)
-
Andrea Bolognani -
lixianglai -
xianglai li