On Tue, Sep 26, 2023 at 03:31:09PM -0300, Daniel Henrique Barboza wrote: > At this moment we do not expose extension properties for vendor CPUs > because that would allow users to change them via command line. The > drawback is that if we were to add an API that shows all CPU properties, > e.g. qmp-query-cpu-model-expansion, we won't be able to show extensions > state of vendor CPUs. > > We have the required machinery to create extension properties for vendor > CPUs while not allowing users to enable extensions. Disabling existing > extensions is allowed since it can be useful for debugging. > > Change the set() callback cpu_set_multi_ext_cfg() to allow enabling > extensions only for generic CPUs. In cpu_add_multi_ext_prop() let's not > set the default values for the properties if we're not dealing with > generic CPUs, otherwise the values set in cpu_init() of vendor CPUs will > be overwritten. And finally, in tcg_cpu_instance_init(), add cpu user > properties for all CPUs. > > For the veyron-v1 CPU, we're now able to disable existing extensions > like smstateen: > > $ ./build/qemu-system-riscv64 --nographic -M virt \ > -cpu veyron-v1,smstateen=false > > But setting extensions that the CPU didn't set during cpu_init(), like > V, is not allowed: > > $ ./build/qemu-system-riscv64 --nographic -M virt \ > -cpu veyron-v1,v=true > qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.v=true: > 'veyron-v1' CPU does not allow enabling extensions
Why should we block the user if they want to enable an extra feature, over and above what is built-in to the CPU model ? Is there some technical reason that prevents this from working ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
