| Message ID | 20241025101959.601048-19-eric.auger@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | kvm/arm: Introduce a customizable aarch64 KVM host model | expand |
On Fri, Oct 25, 2024 at 12:17:37PM +0200, Eric Auger wrote: > This new cpu model takes by default the host cpu values. > However it exposes uint64 SYSREG properties for writable ID reg > fields exposed by the host kernel. Properties are named > SYSREG_<REG>_<FIELD> with REG and FIELD being those used > in linux arch/arm64/tools/sysreg. This done by matching the > writable fields retrieved from the host kernel against the > generated description of sysregs. > > An example of invocation is: > -cpu custom,SYSREG_ID_AA64ISAR0_EL1_DP=0x0 > which sets DP field of ID_AA64ISAR0_EL1 to 0. "SYSREG_" feels kinda redundant to repeat on every single feature. Also, is this naming convention really the same one that users will see when they look at /proc/cpuinfo to view features ? It feels pretty low level to me ? Naming after the registers & fields, would be like configuring x86 CPU features by asking for "SYSREG_EAX_1_ECX_20" instead of saying "vmx" which is the human friendly name. > Signed-off-by: Eric Auger <eric.auger@redhat.com> > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > > --- > > At the moment, the custom model does not support legacy options > of the host cpu model. We need to understand what we do with those > latter (SVE, ...). This means that related KVM ioctl are > not called yet. It will be pretty painful to have to use different feature terminology for different CPU models. Everything in libvirt assuming feature terminology varies per-arch, not per-CPU model. With regards, Daniel
Hi Daniel, On 10/25/24 15:06, Daniel P. Berrangé wrote: > On Fri, Oct 25, 2024 at 12:17:37PM +0200, Eric Auger wrote: >> This new cpu model takes by default the host cpu values. >> However it exposes uint64 SYSREG properties for writable ID reg >> fields exposed by the host kernel. Properties are named >> SYSREG_<REG>_<FIELD> with REG and FIELD being those used >> in linux arch/arm64/tools/sysreg. This done by matching the >> writable fields retrieved from the host kernel against the >> generated description of sysregs. >> >> An example of invocation is: >> -cpu custom,SYSREG_ID_AA64ISAR0_EL1_DP=0x0 >> which sets DP field of ID_AA64ISAR0_EL1 to 0. > "SYSREG_" feels kinda redundant to repeat on every single > feature. I do agree. To be honest this was mostly driven my implementation need for cpu model expansion. Given the high number of props which are getting exposed, I iterate on all props and having a prefix let me return only those SYSREG props. Most probably we can get rid of the prefix by using some generated code as well. > > Also, is this naming convention really the same one that users > will see when they look at /proc/cpuinfo to view features ? It No it is not. I do agree that the custom cpu model is very low level. It is very well suited to test all series turning ID regs as writable but this would require an extra layer that adapts /proc/cpuinfo feature level to this regid/field abstraction. In /cpu/proc you will see somethink like: Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp > feels pretty low level to me ? Naming after the registers & > fields, would be like configuring x86 CPU features by asking > for "SYSREG_EAX_1_ECX_20" instead of saying "vmx" which is the > human friendly name. agreed. > > >> Signed-off-by: Eric Auger <eric.auger@redhat.com> >> Signed-off-by: Cornelia Huck <cohuck@redhat.com> >> >> --- >> >> At the moment, the custom model does not support legacy options >> of the host cpu model. We need to understand what we do with those >> latter (SVE, ...). This means that related KVM ioctl are >> not called yet. > It will be pretty painful to have to use different feature > terminology for different CPU models. Everything in libvirt > assuming feature terminology varies per-arch, not per-CPU > model. Actually as far as I understand those regids/fields would fit all kind of aarch64 Cortex-A CPUs. So they wouldn't vary per-CPU (I mean their terminology. Their availability will). Thanks Eric > > > With regards, > Daniel
On Fri, Oct 25, 2024 at 03:18:25PM +0200, Eric Auger wrote: > Hi Daniel, > > On 10/25/24 15:06, Daniel P. Berrangé wrote: > > On Fri, Oct 25, 2024 at 12:17:37PM +0200, Eric Auger wrote: > >> This new cpu model takes by default the host cpu values. > >> However it exposes uint64 SYSREG properties for writable ID reg > >> fields exposed by the host kernel. Properties are named > >> SYSREG_<REG>_<FIELD> with REG and FIELD being those used > >> in linux arch/arm64/tools/sysreg. This done by matching the > >> writable fields retrieved from the host kernel against the > >> generated description of sysregs. > >> > >> An example of invocation is: > >> -cpu custom,SYSREG_ID_AA64ISAR0_EL1_DP=0x0 > >> which sets DP field of ID_AA64ISAR0_EL1 to 0. > > "SYSREG_" feels kinda redundant to repeat on every single > > feature. > > I do agree. To be honest this was mostly driven my implementation need > for cpu model expansion. Given the high number of props which are > getting exposed, I iterate on all props and having a prefix let me > return only those SYSREG props. Most probably we can get rid of the > prefix by using some generated code as well. > > > > Also, is this naming convention really the same one that users > > will see when they look at /proc/cpuinfo to view features ? It > No it is not. I do agree that the custom cpu model is very low level. It > is very well suited to test all series turning ID regs as writable but > this would require an extra layer that adapts /proc/cpuinfo feature > level to this regid/field abstraction. > > In /cpu/proc you will see somethink like: > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp > asimdhp cpuid asimdrdm lrcpc dcpop asimddp Right, IMHO, this is the terminology that QEMU must use in user facing APIs. On x86 we have a conversion tables for named features to register bits https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/cpu.c#L914 and libvirt does similar https://gitlab.com/libvirt/libvirt/-/blob/master/src/cpu_map/x86_features.xml Yep, it is more work, but it is also much better for humans IMHO. > > feels pretty low level to me ? Naming after the registers & > > fields, would be like configuring x86 CPU features by asking > > for "SYSREG_EAX_1_ECX_20" instead of saying "vmx" which is the > > human friendly name. > agreed. > >> At the moment, the custom model does not support legacy options > >> of the host cpu model. We need to understand what we do with those > >> latter (SVE, ...). This means that related KVM ioctl are > >> not called yet. > > It will be pretty painful to have to use different feature > > terminology for different CPU models. Everything in libvirt > > assuming feature terminology varies per-arch, not per-CPU > > model. > Actually as far as I understand those regids/fields would fit all kind > of aarch64 Cortex-A CPUs. So they wouldn't vary per-CPU (I mean their > terminology. Their availability will). What I mean is can we define named models for various different vendor's Cortex-A silicon and just use that without needing to toggle features, except in rare cases. With regards, Daniel
diff --git a/target/arm/cpu.c b/target/arm/cpu.c index 454d546feb..e5ac3c3e75 100644 --- a/target/arm/cpu.c +++ b/target/arm/cpu.c @@ -1990,6 +1990,21 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp) return; } + /* + * If we failed to retrieve the set of writable ID registers for a "custom" + * CPU model, report it here. + * In case we did get the set of writable ID registers, set the features to + * the configured values here and perform some sanity checks. + */ + if (cpu->writable_id_regs == WRITABLE_ID_REGS_NOT_DISCOVERABLE) { + error_setg(errp, "Host kernel does not support discovering " + "writable id registers"); + return; + } else if (cpu->writable_id_regs == WRITABLE_ID_REGS_FAILED) { + error_setg(errp, "Failed to discover writable id registers"); + return; + } + if (!cpu->gt_cntfrq_hz) { /* * 0 means "the board didn't set a value, use the default". (We also diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c index 86b0797d4b..f10cc4ef8f 100644 --- a/target/arm/cpu64.c +++ b/target/arm/cpu64.c @@ -20,6 +20,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qemu/error-report.h" #include "cpu.h" #include "cpregs.h" #include "qemu/module.h" @@ -35,6 +36,8 @@ #include "cpu-features.h" #include "cpregs.h" #include "cpu-custom.h" +#include "cpu-sysregs.h" +#include "trace.h" void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp) { @@ -742,6 +745,153 @@ static void aarch64_max_initfn(Object *obj) } } +#ifdef CONFIG_KVM + +static ARM64SysRegField *get_field(int i, ARM64SysReg *reg) +{ + GList *l; + + for (l = reg->fields; l; l = l->next) { + ARM64SysRegField *field = (ARM64SysRegField *)l->data; + + if (i >= field->lower && i <= field->upper) { + return field; + } + } + return NULL; +} + +static void set_sysreg_prop(Object *obj, Visitor *v, + const char *name, void *opaque, + Error **errp) +{ + ARM64SysRegField *field = (ARM64SysRegField *)opaque; + ARMCPU *cpu = ARM_CPU(obj); + IdRegMap *idregs = &cpu->isar.idregs; + uint64_t old, value, mask; + int lower = field->lower; + int upper = field->upper; + int length = upper - lower + 1; + int index = field->index; + + if (!visit_type_uint64(v, name, &value, errp)) { + return; + } + + if (length < 64 && value > ((1 << length) - 1)) { + error_setg(errp, + "idreg %s set value (0x%lx) exceeds length of field (%d)!", + name, value, length); + return; + } + + mask = MAKE_64BIT_MASK(lower, length); + value = value << lower; + old = idregs->regs[index]; + idregs->regs[index] = old & ~mask; + idregs->regs[index] |= value; + trace_set_sysreg_prop(name, old, mask, value, idregs->regs[index]); +} + +static void get_sysreg_prop(Object *obj, Visitor *v, + const char *name, void *opaque, + Error **errp) +{ + ARM64SysRegField *field = (ARM64SysRegField *)opaque; + ARMCPU *cpu = ARM_CPU(obj); + IdRegMap *idregs = &cpu->isar.idregs; + int index = field->index; + + error_report("%s %s", __func__, name); + visit_type_uint64(v, name, &idregs->regs[index], errp); + trace_get_sysreg_prop(name, idregs->regs[index]); +} + +/* + * decode_idreg_writemap: Generate props for writable fields + * + * @obj: CPU object + * @index: index of the sysreg + * @map: writable map for the sysreg + * @reg: description of the sysreg + */ +static int +decode_idreg_writemap(Object *obj, int index, uint64_t map, ARM64SysReg *reg) +{ + int i = ctz64(map); + int nb_sysreg_props = 0; + + while (map) { + ARM64SysRegField *field = get_field(i, reg); + int lower, upper; + uint64_t mask; + char *prop_name; + + if (!field) { + /* the field cannot be matched to any know id named field */ + warn_report("%s bit %d of %s is writable but cannot be matched", + __func__, i, reg->name); + warn_report("%s is cpu-sysreg-properties.c up to date?", __func__); + map = map & ~BIT_ULL(i); + i = ctz64(map); + continue; + } + lower = field->lower; + upper = field->upper; + prop_name = g_strdup_printf("SYSREG_%s_%s", reg->name, field->name); + trace_decode_idreg_writemap(field->name, lower, upper, prop_name); + object_property_add(obj, prop_name, "uint64", + get_sysreg_prop, set_sysreg_prop, NULL, field); + nb_sysreg_props++; + + mask = MAKE_64BIT_MASK(lower, upper - lower + 1); + map = map & ~mask; + i = ctz64(map); + } + trace_nb_sysreg_props(reg->name, nb_sysreg_props); + return 0; +} + +/* analyze the writable mask and generate properties for writable fields */ +static int expose_idreg_properties(Object *obj, IdRegMap *map, + ARM64SysReg *regs) +{ + int i; + + for (i = 0; i < NR_ID_REGS; i++) { + uint64_t mask = map->regs[i]; + + if (mask) { + /* reg @i has some writable fields, decode them */ + decode_idreg_writemap(obj, i, mask, ®s[i]); + } + } + return 0; +} + +static void aarch64_customcpu_initfn(Object *obj) +{ + ARMCPU *cpu = ARM_CPU(obj); + int ret; + + cpu->writable_map = g_malloc(sizeof(IdRegMap)); + + /* discover via KVM_ARM_GET_REG_WRITABLE_MASKS */ + ret = kvm_arm_get_writable_id_regs(cpu, cpu->writable_map); + if (ret) { + /* function will have marked an error */ + return; + } + + /* populate from the host (exhaustive) , validate during realize */ + kvm_arm_set_cpu_features_from_host(cpu, true); + + /* generate SYSREG properties according to writable masks */ + expose_idreg_properties(obj, cpu->writable_map, arm64_id_regs); +} + +#endif + static const ARMCPUInfo aarch64_cpus[] = { { .name = "cortex-a57", .initfn = aarch64_a57_initfn }, { .name = "cortex-a53", .initfn = aarch64_a53_initfn }, @@ -749,6 +899,9 @@ static const ARMCPUInfo aarch64_cpus[] = { #if defined(CONFIG_KVM) || defined(CONFIG_HVF) { .name = "host", .initfn = aarch64_host_initfn }, #endif +#ifdef CONFIG_KVM + { .name = "custom", .initfn = aarch64_customcpu_initfn }, +#endif }; static bool aarch64_cpu_get_aarch64(Object *obj, Error **errp) diff --git a/target/arm/trace-events b/target/arm/trace-events index 668acf94ab..1b4bd5ab14 100644 --- a/target/arm/trace-events +++ b/target/arm/trace-events @@ -15,3 +15,9 @@ arm_gt_update_irq(int timer, int irqstate) "gt_update_irq: timer %d irqstate %d" kvm_arm_fixup_msi_route(uint64_t iova, uint64_t gpa) "MSI iova = 0x%"PRIx64" is translated into 0x%"PRIx64 get_host_cpu_idregs(const char *name, uint64_t value) "scratch vcpu gost value for %s is 0x%"PRIx64 kvm_arm_writable_idregs_to_cpreg_list(const char *name, uint64_t previous, uint64_t new) "%s overwrite default 0x%"PRIx64" with 0x%"PRIx64 + +# cpu64.c +decode_idreg_writemap(const char* name, int lower, int upper, char *prop_name) "%s [%d:%d] is writable (prop %s)" +get_sysreg_prop(const char *name, uint64_t value) "%s 0x%"PRIx64 +set_sysreg_prop(const char *name, uint64_t old, uint64_t mask, uint64_t field_value, uint64_t new) "%s old reg value=0x%"PRIx64" mask=0x%"PRIx64" new field value=0x%"PRIx64" new reg value=0x%"PRIx64 +nb_sysreg_props(const char *name, int count) "%s: %d SYSREG properties"