[pve-devel] [PATCH v6 qemu-server 04/12] Adapt CPUConfig to handle custom models

[Thomas Lamprecht]

On 11/21/19 3:53 PM, Stefan Reiter wrote:
> Turn CPUConfig into a SectionConfig with parsing/writing support for
> custom CPU models. IO is handled using cfs.
> 
> Namespacing will be provided using "custom-" prefix for custom model
> names (in VM config only, cpu-models.conf will contain unprefixed
> names).
> 
> Signed-off-by: Stefan Reiter <s.reiter at proxmox.com>
> ---
> 
> Depends on updated pve-cluster.
> 
> 
>  PVE/QemuServer/CPUConfig.pm | 46 ++++++++++++++++++++++++++++++++++---
>  1 file changed, 43 insertions(+), 3 deletions(-)
> 
> diff --git a/PVE/QemuServer/CPUConfig.pm b/PVE/QemuServer/CPUConfig.pm
> index 86febe8..be16eba 100644
> --- a/PVE/QemuServer/CPUConfig.pm
> +++ b/PVE/QemuServer/CPUConfig.pm
> @@ -4,15 +4,25 @@ use strict;
>  use warnings;
>  
>  use PVE::JSONSchema;
> +use PVE::Cluster qw(cfs_register_file cfs_read_file);
>  use PVE::QemuServer::Helpers qw(min_version);
>  
> -use base qw(Exporter);
> +use base qw(PVE::SectionConfig Exporter);
>  
>  our @EXPORT_OK = qw(
>  print_cpu_device
>  get_cpu_options
>  );
>  
> +my $default_filename = "cpu-models.conf";
> +cfs_register_file($default_filename,
> +		  sub { PVE::QemuServer::CPUConfig->parse_config(@_); },
> +		  sub { PVE::QemuServer::CPUConfig->write_config(@_); });


hmm, it could be nice to call it "guest-resources.cfg" and make the cpu models
just a section in there: 
[CPU-MODEL]

and to have other virtual guest related cluster wide configs in there too..
But that's hard to do, alone the place where we then would put the parsers
wouldn't be easy to handle.

As somewhat a compromise we could add at leas a directory, top-level /etc/pve
isn't exactly empty anymore.. maybe "virtual-guest/cpu-models.conf" ?

> +
> +sub load_custom_model_conf {
> +    return cfs_read_file($default_filename);
> +}
> +
>  my $cpu_vendor_list = {
>      # Intel CPUs
>      486 => 'GenuineIntel',
> @@ -84,11 +94,20 @@ my $cpu_flag = qr/[+-](@{[join('|', @supported_cpu_flags)]})/;
>  
>  our $cpu_fmt = {
>      cputype => {
> -	description => "Emulated CPU type.",
> +	description => "Emulated CPU type. Can be default or custom name (custom model names must be prefixed with 'custom-').",
>  	type => 'string',
> -	enum => [ sort { "\L$a" cmp "\L$b" } keys %$cpu_vendor_list ],
> +	format_description => 'string',
>  	default => 'kvm64',
>  	default_key => 1,
> +	optional => 1,
> +    },
> +    'reported-model' => {
> +	description => "CPU model and vendor to report to the guest. Must be a QEMU/KVM supported model."
> +		     . " Only valid for custom CPU model definitions, default models will always report themselves to the guest OS.",
> +	type => 'string',
> +	enum => [ sort { lc("$a") cmp lc("$b") } keys %$cpu_vendor_list ],
> +	default => 'kvm64',
> +	optional => 1,
>      },
>      hidden => {
>  	description => "Do not identify as a KVM virtual machine.",
> @@ -114,6 +133,24 @@ our $cpu_fmt = {
>      },
>  };
>  
> +# Section config settings
> +my $defaultData = {
> +    # shallow copy, since SectionConfig modifies propertyList internally
> +    propertyList => { %$cpu_fmt },
> +};
> +
> +sub private {
> +    return $defaultData;
> +}
> +
> +sub options {
> +    return { %$cpu_fmt };
> +}
> +
> +sub type {
> +    return 'cpu-model';
> +}
> +
>  # Print a QEMU device node for a given VM configuration for hotplugging CPUs
>  sub print_cpu_device {
>      my ($conf, $id) = @_;
> @@ -229,4 +266,7 @@ sub add_hyperv_enlightenments {
>      }
>  }
>  
> +__PACKAGE__->register();
> +__PACKAGE__->init();
> +
>  1;
>