GitLab

Instead of overwriting the existing re-allocated memory, create new
memory when for the incoming guest RAM pages.

While trying to migrate disaggregated memory as normal memory via TCP, a
limitation was found in the code due to the hostmem remote backends not
being allocated at the destination VM. In particular, the ram migration
code was trying to resolve the incoming RAMBlock, but it was failing as
the RAMBlocks at the destination VM were not initialised yet (thus, they
did not have the "host" pointer).

Rework and simplify the way we migrate the remote section IDs of
disaggregated memory.

Add an option in the HMP command line to disable the "disaggregated
migration": migrate_set_disaggregated [off,on]

This option forces the whole ram to be migrate as normal memory.

With a section of 512MB (=1 KVM slot) we were able to scale only up to
16GB. Inspired by Power setup in kernel, changed to 512 slots.
NOTE: The same change has to be done at host side in the file:
`arch/arm64/include/asm/kvm_host.h`

        #define KVM_USER_MEM_SLOTS 32   // -> 512

Look into virtio_mmio_realizefn for a comment explaining a rationale for
that. This allows to resize the memory by 238 sections at once. Still,
this could be done more properly via virtqueues but this is a quick hack
to have it working.

Alert the user when possibly harmful situations are occurring while
using the locking mechanism of a shared memory.

The memory region of each dboxmem device can be reused to serve
different shared memory by updating its host pointer. We need to make
sure that the corresponding mapping gets updated. To do so, we
remove-add the memory region. Make also sure the memory region does not
get destroyed while deleting it via memory_region_del_subregion().

At the moment, memory_region_init_ram_remote() is used only by the virt
platform, which already vmstate_register's the RAM memory by using
memory_region_allocate_system_memory(). Moreover, the hostmem-remote and
hostmem-dboxshm backend should not vmstate_register the RAM by
themselves. Therefore, remove the vmstate registration of the memory
from memory_region_init_ram_remote() and rename it as nomigrate to align
to the rest of the code's convention.

Restore the section UUID while processing an incoming migration. Not
doing so would lead to the systematic failure of any subsequent
migration.

With MTTCG some things changed. In particular, the locking thread used
to handle mem_lock() and mem_unlock() can inject an interrupt without
the global lock being held. This will cause later asserts to fail. Avoid
this by taking the global lock to inject the interrupt.

This device, heavily base on ivshmem, allow to expose disaggregate
memory to the guest, via a PCI bar. The allocation of memory (or
attachment to existing disaggregated memory) is done at runtime.

Now that we allow a memory region to be initiated without actual
allocation of backing memory, introduce this function to allow the
afterhand allocation of memory.

Introduce a remote-specific memory region initiator.

This will simplify the future changes by better factorizing the code.

N.B.: qemu_ram_alloc() is not include in this function as it doesn't
behave commonly in all the use cases (see following commit).

When adding a new RAM block which is backed by remote memory, if the
ram_block->host pointer in NULL, do not populate it by allocating memory
through phys_mem_alloc(). The actual allocation of memory (and thus the
population of ram_block->host) will be done later on.

This will also avoid the "dance" of overriding/restoring the
phys_mem_alloc() pointer before and after calling
memory_region_init_ram() (which in turns would call ram_block_add()).

Add new memory backend to allocate guest memory from disaggregated
pools. Moreover, adapt the migration code to not copy the RAM memory, as
it is disaggregated.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

This reverts commit 1b2503fcf7b5932c5a3779ca2ceb92bd403c4ee7.

Unfortunately this fix regresses console handling on MIPS Malta;
since the mux ctrl-a b bug is not a regression since 2.11, we
take the conservative approach and just drop it from 2.12.
Reported-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Without bounding the increment, we can overflow exp either here
in scalbn_decomposed or when adding the bias in round_canonical.
This can result in e.g. underflowing to 0 instead of overflowing
to infinity.

The old softfloat code did bound the increment.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Commit fb5e19d2 originally fixed the
regression, but was inadvertently broken again in merge commit
2d6752d3.

Fixes:
https://bugs.launchpad.net/qemu/+bug/1654137

Cc: qemu-stable@nongnu.org
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20180416181844.7851-1-marcandre.lureau@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

In commit 8c5931de we added support for SVE extended
sigframe records.  These mean that the signal frame might now be
larger than the size of the target_rt_sigframe record, so make sure
we call lock_user on the entire frame size when we're creating it.
(The code for restoring the signal frame already correctly handles
the extended records by locking the 'extra' section separately to the
main section.)

In particular, this fixes a bug even for non-SVE signal frames,
because it extends the locked section to cover the
target_rt_frame_record. Previously this was part of 'struct
target_rt_sigframe', but in commit e1eecd1d we pulled
it out into its own struct, and so locking the target_rt_sigframe
alone doesn't cover it. This bug would mean that we would fail
to correctly handle the case where a signal was taken with
SP pointing 16 bytes into an unwritable page, with the page
immediately below it in memory being writable....

The assumption in the cpu->max_features code is that anything
enabled on GET_SUPPORTED_CPUID should be enabled on "-cpu host".
This shouldn't be the case for FEAT_KVM_HINTS.

This adds a new FeatureWordInfo::no_autoenable_flags field, that
can be used to prevent FEAT_KVM_HINTS bits to be enabled
automatically.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180410211534.26079-1-ehabkost@redhat.com>
Tested-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

When IOMMU is enabled, we store virtqueue metadata as iova (though it
may has _phys suffix) and access them through dma helpers. Any
translation failures could be reported by IOMMU.

In this case, trying to validate iova against gpa won't work and will
cause a false error reporting. So this patch bypasses the ring
verification if IOMMU is enabled which is similar to the behavior
before 0ca1fd2d that calls vhost_memory_map() which is a nop when
IOMMU is enabled.

Fixes: 0ca1fd2d ("vhost: Simplify ring verification checks")
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>