[RFC PATCH qemu-server] capture obscure error related to phys-bits

[Maximiliano Sandoval <m.sandoval@proxmox.com>]

Provides context to the somewhat obscure error message:

kvm: Address space limit 0xffffffffff < 0x2877fffffff phys-bits too low (40)

when failing to start a VM due to the CPU's phys-bits option being too
small. Note that by default phys-bit is read from the CPU address size
capped to 40, and that 0xffffffffff = (1 << 40) - 1 (cf. [1]) would be
what most modern systems would see nowadays.

In the example above one would need to, aptly, set phys-bits to at least
42 to avoid running into this issue.

The computation for the max address size required for QEMU is not
straight forward and depends on the machine type among other factors so
we cannot easily try to detect the error before it happens and bump the
value of phys-bits (if not explicitly set in the VM config)
preemptively. One can speculate that a guest with 1 TiB of memory
configured would run into this issue as 0xffffffffff < 0x10000000000
too.

[1] https://gitlab.com/qemu-project/qemu/-/blob/v10.2.1/hw/i386/pc.c#L877

Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
---

The place where the $run_params{logfunc} is set is obviously wrong, my host in
particular runs into the elsif branch for AuthenticAMD CPUs. I was hoping to
gather some feedback before modifying the logging mechanism.

In general cathing log messages like this is not a good idea, but here I was not
sure if there is a sane venue to make this error more understandable.

Notes:
    This came up in enterprise support.
    
    In this case the machine had a CPU address size of 48 bits and the guest
    in question had 1.572.864 MiB of memory assigned.

 src/PVE/QemuServer.pm | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
index 09e7a19b..58aa538a 100644
--- a/src/PVE/QemuServer.pm
+++ b/src/PVE/QemuServer.pm
@@ -5432,6 +5432,22 @@ my $log_filter_catch_outdated_zen5_firmware = sub {
     }
 };
 
+my $log_filter_catch_host_phys_bits_too_small = sub {
+    my ($line) = @_;
+    print "$line\n";
+    if ($line =~
+        m/Address space limit (?<curr_size>0x[0-9A-Fa-f]+) < (?<target_size>0x[0-9A-Fa-f]+) phys-bits too low \((?<phys_bits>[0-9]+)\)/
+    ) {
+        log_warn(
+            "phys-bits=$+{phys_bits} is configured for the CPU. This results in an address"
+                . " space of size '(1 << phys-bits) - 1 = $+{curr_size}' which is smaller than"
+                . " what QEMU expects ($+{target_size}) for the VM's configured memory size."
+                . " Please increase its value to satisfy the previous assertion.\nBy default"
+                . " phys-bits will be set to the host's CPU address size capped to 40. Its value "
+                . " can be set via\nqm set <vmid> --cpu=...,phys-bits=<new value>");
+    }
+};
+
 # see vm_start_nolock for parameters, additionally:
 # migrate_opts:
 #   storagemap = parsed storage map for allocating NBD disks
@@ -5708,6 +5724,8 @@ sub vm_start_nolock {
         $run_params{logfunc} = sub { print "QEMU: $_[0]\n" };
     } elsif ($cpuinfo->{vendor} eq 'AuthenticAMD' && $cpuinfo->{family} == 26) {
         $run_params{logfunc} = $log_filter_catch_outdated_zen5_firmware;
+    } else {
+        $run_params{logfunc} = $log_filter_catch_host_phys_bits_too_small;
     }
 
     my %systemd_properties = (
-- 
2.47.3