[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] [RFC v3 05/15] hw/arm/virt: handle max_vm_ph
From: |
David Hildenbrand |
Subject: |
Re: [Qemu-arm] [Qemu-devel] [RFC v3 05/15] hw/arm/virt: handle max_vm_phys_shift conflicts on migration |
Date: |
Wed, 4 Jul 2018 13:53:40 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 03.07.2018 21:32, Auger Eric wrote:
> Hi David,
> On 07/03/2018 08:41 PM, David Hildenbrand wrote:
>> On 03.07.2018 09:19, Eric Auger wrote:
>>> When migrating a VM, we must make sure the destination host
>>> supports as many IPA bits as the source. Otherwise the migration
>>> must fail.
>>>
>>> We add a VMState infrastructure to machvirt. On pre_save(),
>>> the current source max_vm_phys_shift is saved.
>>>
>>> On destination, we cannot use this information when creating the
>>> VM. The VM is created using the max value reported by the
>>> destination host - or the kvm_type inherited value -. However on
>>> post_load() we can check that this value is compatible with the
>>> source saved value.
>>
>> Just wondering, how exactly is the guest able to detect the 42b (e.g. vs
>> 42b) configuration?
>
> the source IPA size is saved in the VMState. When restoring it on
> post_load we check against the current IPA size (corresponding to the
> max the destination KVM does support). The destination IPA size is
> chosen before creating the destination VM. If the destination IPA size
> is less than the source IPA size, we fail the migration.
>
> Hope this helps
No, I asked if the *guest* is able to distinguish e.g. 43 from 44 or if
the device memory setup is sufficient.
Once you create the machine, you setup device memory (using the maxmem
parameter).
>From that, you directly know how big the largest guest physical address
will be (e.g. 2TB + (maxram_size - ram_size)). You can check that
against max_vm_phys_shift and error out.
During migration, source and destination have to have the same qemu
cmdline, especially same maxmem parameter. So you would catch an invalid
setup on the destination, without manually migrating and checking
max_vm_phys_shift.
However (that's why I am asking) if the guest can spot the difference
between e.g. 43 and 44, then you should migrate and check. If it is
implicitly handled by device memory position and size, you should not
migrate it.
>
> Thanks
>
> Eric
>
>>
--
Thanks,
David / dhildenb
- [Qemu-arm] [RFC v3 04/15] hw/arm/virt: support kvm_type property, (continued)
- [Qemu-arm] [RFC v3 04/15] hw/arm/virt: support kvm_type property, Eric Auger, 2018/07/03
- [Qemu-arm] [RFC v3 09/15] hw/arm/boot: Expose the PC-DIMM nodes in the DT, Eric Auger, 2018/07/03
- [Qemu-arm] [RFC v3 15/15] hw/arm/virt: Add nvdimm and nvdimm-persistence options, Eric Auger, 2018/07/03
- [Qemu-arm] [RFC v3 01/15] linux-headers: header update for KVM/ARM KVM_ARM_GET_MAX_VM_PHYS_SHIFT, Eric Auger, 2018/07/03
- [Qemu-arm] [RFC v3 10/15] acpi: move build_srat_hotpluggable_memory to generic ACPI source, Eric Auger, 2018/07/03
- [Qemu-arm] [RFC v3 12/15] nvdimm: use configurable ACPI IO base and size, Eric Auger, 2018/07/03
- [Qemu-arm] [RFC v3 13/15] hw/arm/virt: Add nvdimm hot-plug infrastructure, Eric Auger, 2018/07/03
- [Qemu-arm] [RFC v3 05/15] hw/arm/virt: handle max_vm_phys_shift conflicts on migration, Eric Auger, 2018/07/03
Re: [Qemu-arm] [RFC v3 00/15] ARM virt: PCDIMM/NVDIMM at 2TB, Igor Mammedov, 2018/07/18