[PATCH 0/8] riscv: detecting user choice in TCG extensions

Daniel Henrique Barboza posted 8 patches 9 months, 1 week ago
Failed in applying to current master (apply log)
There is a newer version of this series
target/riscv/cpu.c | 392 +++++++++++++++++++++++++++++----------------
target/riscv/cpu.h |   2 +
target/riscv/kvm.c |   8 +-
3 files changed, 261 insertions(+), 141 deletions(-)
[PATCH 0/8] riscv: detecting user choice in TCG extensions
Posted by Daniel Henrique Barboza 9 months, 1 week ago
Hi,

This series, based on the work done in "[PATCH for-8.2 v6 00/11] riscv:
add 'max' CPU, deprecate 'any'", aims to solve two problem we have in
TCG properties handling:

- we are not checking for priv_ver when auto-enabling extensions during
  realize();

- we are not able to honor user choice during validation because we're
  not able to tell if the user set an extension flag or not.

The solution adopted here is a modification of what we did in the RISC-V
KVM driver for 8.1. Instead of adding an 'user_set' flag and doing a
linear search in all the extensions (now split between multiple arrays),
we'll use a hash to store the 'offset' value of the property that the
user set in the command line in the set() callback of the property. The
existence of an entry in the hash indicates that the user set a value
for that extension, and the store val indicates what the user set. This
can be used in the future in case we decide to overwrite the user input
in a corner case.

Aside from this detail, the changes to convert the existing code to use
the new structure (RISCVCPUMultiExtConfig) is quite similar to what was
already done before in the KVM driver.

I also added a new concept called 'auto_update' (any other name is
welcome) to refer to the action of changing extension state during
realize() without user knowledge. All these cases are now wrapped in a
cpu_cfg_ext_auto_update() function that checks if the priv_ver is valid
and if the user set the extension to an specific val. User choice
prevails in this case, regardless of the noble intentions we have when
auto-updating an extensions (e.g. extension dependencies).

Yes, users will have an easier time breaking validation and guest boot,
but that's the idea. Users will have more power, and the adequate dose
of responsibility that comes with it.


Daniel Henrique Barboza (8):
  target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabled
  target/riscv: make CPUCFG() macro public
  target/riscv/cpu.c: introduce cpu_cfg_ext_auto_update()
  target/riscv/cpu.c: use cpu_cfg_ext_auto_update() during realize()
  target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig
  target/riscv: use isa_ext_update_enabled() in
    init_max_cpu_extensions()
  target/riscv/cpu.c: honor user choice in cpu_cfg_ext_auto_update()
  target/riscv/cpu.c: consider user option with RVG

 target/riscv/cpu.c | 392 +++++++++++++++++++++++++++++----------------
 target/riscv/cpu.h |   2 +
 target/riscv/kvm.c |   8 +-
 3 files changed, 261 insertions(+), 141 deletions(-)

-- 
2.41.0