(CCing libvir-list, and people who were included in the OVMF
thread[1])
[1]
https://lore.kernel.org/qemu-devel/99779e9c-f05f-501b-b4be-ff719f140...@canonical.com/
On Fri, Jun 19, 2020 at 05:53:44PM +0200, Mohammed Gamal wrote:
> If the CPU doesn't support GUEST_MAXPHYADDR < HOST_MAXPHYADDR we
> let QEMU choose to use the host MAXPHYADDR and print a warning to the
> user.
>
> Signed-off-by: Mohammed Gamal <mga...@redhat.com>
> ---
> target/i386/cpu.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index b1b311baa2..91c57117ce 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -6589,6 +6589,17 @@ static void x86_cpu_realizefn(DeviceState *dev, Error
> **errp)
> uint32_t host_phys_bits = x86_host_phys_bits();
> static bool warned;
>
> + /*
> + * If host doesn't support setting physical bits on the guest,
> + * report it and return
> + */
> + if (cpu->phys_bits < host_phys_bits &&
> + !kvm_has_smaller_maxphyaddr()) {
> + warn_report("Host doesn't support setting smaller phys-bits."
> + " Using host phys-bits\n");
> + cpu->phys_bits = host_phys_bits;
> + }
> +
This looks like a regression from existing behavior. Today,
using smaller phys-bits doesn't crash most guests, and still
allows live migration to smaller hosts. I agree using the host
phys-bits is probably a better default, but we shouldn't override
options set explicitly in the command line.
Also, it's important that we work with libvirt and management
software to ensure they have appropriate APIs to choose what to
do when a cluster has hosts with different MAXPHYADDR.
> /* Print a warning if the user set it to a value that's not the
> * host value.
> */
> --
> 2.26.2
>
--
Eduardo
