All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Auger Eric <eric.auger@redhat.com>,
	eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
	qemu-arm@nongnu.org, peter.maydell@linaro.org,
	shameerali.kolothum.thodi@huawei.com, imammedo@redhat.com
Cc: wei@redhat.com, drjones@redhat.com, david@gibson.dropbear.id.au,
	dgilbert@redhat.com, agraf@suse.de
Subject: Re: [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	[thread overview]
Message-ID: <401ccabc-584a-8754-bcb6-b4fdea6fe836@redhat.com> (raw)
In-Reply-To: <2513e4a9-8980-6274-b933-a5e107b32da5@redhat.com>

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

  reply	other threads:[~2018-07-04 11:53 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-03  7:19 [Qemu-devel] [RFC v3 00/15] ARM virt: PCDIMM/NVDIMM at 2TB Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 01/15] linux-headers: header update for KVM/ARM KVM_ARM_GET_MAX_VM_PHYS_SHIFT Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 02/15] hw/boards: Add a MachineState parameter to kvm_type callback Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 03/15] kvm: add kvm_arm_get_max_vm_phys_shift Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 04/15] hw/arm/virt: support kvm_type property Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 05/15] hw/arm/virt: handle max_vm_phys_shift conflicts on migration Eric Auger
2018-07-03 18:41   ` David Hildenbrand
2018-07-03 19:32     ` Auger Eric
2018-07-04 11:53       ` David Hildenbrand [this message]
2018-07-04 12:50         ` Auger Eric
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 06/15] hw/arm/virt: Allocate device_memory Eric Auger
2018-07-03 18:25   ` David Hildenbrand
2018-07-03 19:27     ` Auger Eric
2018-07-04 12:05       ` David Hildenbrand
2018-07-05 11:42         ` Auger Eric
2018-07-05 11:54           ` David Hildenbrand
2018-07-05 12:00             ` Auger Eric
2018-07-05 12:09               ` David Hildenbrand
2018-07-05 12:17                 ` Auger Eric
2018-07-05 13:19                   ` Shameerali Kolothum Thodi
2018-07-05 14:27                     ` Auger Eric
2018-07-11 13:17                       ` Igor Mammedov
2018-07-12 14:22                         ` Auger Eric
2018-07-12 14:45                           ` Andrew Jones
2018-07-12 14:53                             ` Auger Eric
2018-07-12 15:15                               ` Andrew Jones
2018-07-18 13:00                               ` Igor Mammedov
2018-08-08  9:33                                 ` Auger Eric
2018-08-09  8:45                                   ` Igor Mammedov
2018-08-09  9:54                                     ` Auger Eric
2018-07-18 13:05   ` Igor Mammedov
2018-08-08  9:33     ` Auger Eric
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 07/15] hw/arm/virt: Add memory hotplug framework Eric Auger
2018-07-03 18:28   ` David Hildenbrand
2018-07-03 19:28     ` Auger Eric
2018-07-03 18:44   ` David Hildenbrand
2018-07-03 19:34     ` Auger Eric
2018-07-04 11:47       ` David Hildenbrand
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 08/15] hw/arm/boot: introduce fdt_add_memory_node helper Eric Auger
2018-07-18 14:04   ` Igor Mammedov
2018-08-08  9:44     ` Auger Eric
2018-08-09  8:57       ` Igor Mammedov
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 09/15] hw/arm/boot: Expose the PC-DIMM nodes in the DT Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 10/15] acpi: move build_srat_hotpluggable_memory to generic ACPI source Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 11/15] hw/arm/virt-acpi-build: Add PC-DIMM in SRAT Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 12/15] nvdimm: use configurable ACPI IO base and size Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 13/15] hw/arm/virt: Add nvdimm hot-plug infrastructure Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 14/15] hw/arm/boot: Expose the pmem nodes in the DT Eric Auger
2018-07-03  7:19 ` [Qemu-devel] [RFC v3 15/15] hw/arm/virt: Add nvdimm and nvdimm-persistence options Eric Auger
2018-07-18 14:08 ` [Qemu-devel] [RFC v3 00/15] ARM virt: PCDIMM/NVDIMM at 2TB Igor Mammedov
2018-10-18 12:56   ` Auger Eric
2018-10-03 13:49 ` Auger Eric
2018-10-03 14:13   ` Dr. David Alan Gilbert
2018-10-03 14:42     ` Auger Eric
2018-10-03 14:46       ` Dr. David Alan Gilbert
2018-10-04 11:11   ` Igor Mammedov
2018-10-04 11:32     ` Auger Eric
2018-10-04 12:02       ` David Hildenbrand
2018-10-04 12:07         ` Auger Eric
2018-10-04 13:16       ` Igor Mammedov
2018-10-04 14:16         ` Dr. David Alan Gilbert
2018-10-05  8:18           ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=401ccabc-584a-8754-bcb6-b4fdea6fe836@redhat.com \
    --to=david@redhat.com \
    --cc=agraf@suse.de \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgilbert@redhat.com \
    --cc=drjones@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=wei@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.