Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Sep 19, 2023
  3. Sep 12, 2023
  5. Sep 11, 2023
    • Avihai Horon's avatar
      vfio/migration: Add P2P support for VFIO migration · 94f775e4
      Avihai Horon authored 
      
VFIO migration uAPI defines an optional intermediate P2P quiescent
state. While in the P2P quiescent state, P2P DMA transactions cannot be
initiated by the device, but the device can respond to incoming ones.
Additionally, all outstanding P2P transactions are guaranteed to have
been completed by the time the device enters this state.

The purpose of this state is to support migration of multiple devices
that might do P2P transactions between themselves.

Add support for P2P migration by transitioning all the devices to the
P2P quiescent state before stopping or starting the devices. Use the new
VMChangeStateHandler prepare_cb to achieve that behavior.

This will allow migration of multiple VFIO devices if all of them
support P2P migration.

Signed-off-by: default avatarAvihai Horon <avihaih@nvidia.com>
Tested-by: default avatarYangHang Liu <yanghliu@redhat.com>
Reviewed-by: default avatarCédric Le Goater <clg@redhat.com>
Signed-off-by: default avatarCédric Le Goater <clg@redhat.com>
      94f775e4
  7. Sep 08, 2023
  9. Sep 07, 2023
  11. Sep 01, 2023
  13. Aug 31, 2023
  15. Aug 30, 2023
    • Alex Bennée's avatar
      docs/style: permit inline loop variables · 4b77429a
      Alex Bennée authored 
      
I've already wasted enough of my time debugging aliased variables in
deeply nested loops. While not scattering variable declarations around
is a good aim I think we can make an exception for stuff used inside a
loop.

Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Acked-by: default avatarMarkus Armbruster <armbru@redhat.com>
Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Message-Id: <20230829161528.2707696-5-alex.bennee@linaro.org>
      4b77429a
    • Daniel P. Berrangé's avatar
      gitlab: enable ccache for many build jobs · 2f7350cd
      Daniel P. Berrangé authored 
      
The `ccache` tool can be very effective at reducing compilation times
when re-running pipelines with only minor changes each time. For example
a fresh 'build-system-fedora' job will typically take 20 minutes on the
gitlab.com shared runners. With ccache this is reduced to as little as
6 minutes.

Normally meson would auto-detect existance of ccache in $PATH and use
it automatically, but the way we wrap meson from configure breaks this,
as we're passing in an config file with explicitly set compiler paths.
Thus we need to add $CCACHE_WRAPPERSPATH to the front of $PATH. For
unknown reasons if doing this in msys though, gcc becomes unable to
invoke 'cc1' when run from meson. For msys we thus set CC='ccache gcc'
before invoking 'configure' instead.

A second problem with msys is that cache misses are incredibly
expensive, so enabling ccache massively slows down the build when
the cache isn't well populated. This is suspected to be a result of
the cost of spawning processes under the msys architecture. To deal
with this we set CCACHE_DEPEND=1 which enables ccache's 'depend_only'
strategy. This avoids extra spawning of the pre-processor during
cache misses, with the downside that is it less likely ccache will
find a cache hit after semantically benign compiler flag changes.
This is the lesser of two evils, as otherwise we can't use ccache
at all under msys and remain inside the job time limit.

If people are finding ccache to hurt their pipelines, it can be
disabled by setting the 'CCACHE_DISABLE=1' env variable against
their gitlab fork CI settings.

Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230804111054.281802-2-berrange@redhat.com>
Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Message-Id: <20230829161528.2707696-2-alex.bennee@linaro.org>
      2f7350cd
  17. Aug 28, 2023
    • Paolo Bonzini's avatar
      Revert "tests: Use separate virtual environment for avocado" · c03f57fd
      Paolo Bonzini authored 
      This reverts commit e8e4298f.

ensuregroup allows to specify both the acceptable versions of avocado,
and a locked version to be used when avocado is not installed as a system
pacakge.  This lets us install avocado in pyvenv/ using "mkvenv.py" and
reuse the distro package on Fedora and CentOS Stream (the only distros
where it's available).

ensuregroup's usage of "(>=..., <=...)" constraints when evaluating
the distro package, and "==" constraints when installing it from PyPI,
makes it possible to avoid conflicts between the known-good version and
a package plugins included in the distro.

This is because package plugins have "==" constraints on the version
that is included in the distro, and, using "pip install avocado==88.1"
on a venv that includes system packages will result in an error:

   avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
   avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.

But at the same time, if the venv does not include a system distribution
of avocado then we can install a known-good version and stick to LTS
releases.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1663


Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      c03f57fd
  19. Aug 24, 2023
  21. Aug 23, 2023
  23. Aug 08, 2023
  25. Aug 01, 2023
  27. Jul 26, 2023
    • Peter Xu's avatar
      docs/migration: Update postcopy bits · f014880a
      Peter Xu authored 
      
We have postcopy recovery but not reflected in the document, do an update
for that.

Add a very small section on postcopy preempt.

Touch up the pagemap section, dropping the unsent map because it's already
been dropped in the source code in commit 1e7cf8c3 ("migration/postcopy:
unsentmap is not necessary for postcopy").

Touch up the postcopy section to remove "network connection" failures as
downside, because now it's not fatal and can be recovered.  Suggested by
Laszlo.

Acked-by: default avatarLaszlo Ersek <lersek@redhat.com>
Signed-off-by: default avatarPeter Xu <peterx@redhat.com>
Reviewed-by: default avatarJuan Quintela <quintela@redhat.com>
Message-ID: <20230706115611.371048-1-peterx@redhat.com>
Signed-off-by: default avatarJuan Quintela <quintela@redhat.com>
      f014880a
    • Juan Quintela's avatar
      migration: skipped field is really obsolete. · 7b24d326
      Juan Quintela authored 
      
Has return zero for more than 10 years.

Specifically we introduced the field in 1.5.0

commit f1c72795
Author: Peter Lieven <pl@kamp.de>
Date:   Tue Mar 26 10:58:37 2013 +0100

    migration: do not sent zero pages in bulk stage

    during bulk stage of ram migration if a page is a
    zero page do not send it at all.
    the memory at the destination reads as zero anyway.

    even if there is an madvise with QEMU_MADV_DONTNEED
    at the target upon receipt of a zero page I have observed
    that the target starts swapping if the memory is overcommitted.
    it seems that the pages are dropped asynchronously.

    this patch also updates QMP to return the number of
    skipped pages in MigrationStats.

but removed its usage in 1.5.3

commit 9ef051e5
Author: Peter Lieven <pl@kamp.de>
Date:   Mon Jun 10 12:14:19 2013 +0200

    Revert "migration: do not sent zero pages in bulk stage"

    Not sending zero pages breaks migration if a page is zero
    at the source but not at the destination. This can e.g. happen
    if different BIOS versions are used at source and destination.
    It has also been reported that migration on pseries is completely
    broken with this patch.

    This effectively reverts commit f1c72795.

Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Message-ID: <20230612193344.3796-2-quintela@redhat.com>
Signed-off-by: default avatarJuan Quintela <quintela@redhat.com>
      7b24d326
  29. Jul 19, 2023
  31. Jul 18, 2023
  33. Jul 10, 2023