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 >> >>> > >
