[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: |
Auger Eric |
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 14:50:28 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
Hi David,
On 07/04/2018 01:53 PM, David Hildenbrand wrote:
> 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.
Ah OK I didn't catch your question. Yes indeed you method is simpler. At
the moment I don't think the guest can make any difference. But the
guest sees the CPU PARange which is fixed currently, as far as I
understand it; also the guest is GPA limited at compilation time with a
given CONFIG_ARM64_PA_BITS_=X config.
So we come back to Dave's remark, if we make CPU PARange match the
max_vm_phys_shift and make the former dynamic, then the guest can see it.
Thanks
Eric
>
> 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
>>
>>>
>
>
- [Qemu-arm] [RFC v3 09/15] hw/arm/boot: Expose the PC-DIMM nodes in the DT, (continued)
- [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