Skip to content
Please note that GitHub no longer supports Internet Explorer.

We recommend upgrading to the latest Microsoft Edge, Google Chrome, or Firefox.

Learn more
Permalink
Branch: ide
Commits on Jan 22, 2020
  1. tests/ide-test: Create a single unit-test covering more PRDT cases

    a13xp0p0v authored and jnsnow committed Dec 23, 2019
    Fuzzing the Linux kernel with syzkaller allowed to find how to crash qemu
    using a special SCSI_IOCTL_SEND_COMMAND. It hits the assertion in
    ide_dma_cb() introduced in the commit a718978 in July 2015.
    Currently this bug is not reproduced by the unit tests.
    
    Let's improve the ide-test to cover more PRDT cases including one
    that causes this particular qemu crash.
    
    The test is developed according to the Programming Interface for
    Bus Master IDE Controller (Revision 1.0 5/16/94).
    
    Signed-off-by: Alexander Popov <alex.popov@linux.com>
    Message-id: 20191223175117.508990-3-alex.popov@linux.com
    Signed-off-by: John Snow <jsnow@redhat.com>
  2. ide: Fix incorrect handling of some PRDTs in ide_dma_cb()

    a13xp0p0v authored and jnsnow committed Dec 23, 2019
    The commit a718978 from July 2015 introduced the assertion which
    implies that the size of successful DMA transfers handled in ide_dma_cb()
    should be multiple of 512 (the size of a sector). But guest systems can
    initiate DMA transfers that don't fit this requirement.
    
    For fixing that let's check the number of bytes prepared for the transfer
    by the prepare_buf() handler. The code in ide_dma_cb() must behave
    according to the Programming Interface for Bus Master IDE Controller
    (Revision 1.0 5/16/94):
    1. If PRDs specified a smaller size than the IDE transfer
       size, then the Interrupt and Active bits in the Controller
       status register are not set (Error Condition).
    2. If the size of the physical memory regions was equal to
       the IDE device transfer size, the Interrupt bit in the
       Controller status register is set to 1, Active bit is set to 0.
    3. If PRDs specified a larger size than the IDE transfer size,
       the Interrupt and Active bits in the Controller status register
       are both set to 1.
    
    Signed-off-by: Alexander Popov <alex.popov@linux.com>
    Reviewed-by: Kevin Wolf <kwolf@redhat.com>
    Message-id: 20191223175117.508990-2-alex.popov@linux.com
    Signed-off-by: John Snow <jsnow@redhat.com>
Commits on Jan 21, 2020
  1. Merge remote-tracking branch 'remotes/philmd-gitlab/tags/edk2-next-20…

    pm215 committed Jan 21, 2020
    …200121' into staging
    
    EDK2 firmware patches
    
    Another set of build-sys patches, to help building the firmware
    binaries we use for testing. We almost have reproducible builds.
    
    # gpg: Signature made Tue 21 Jan 2020 15:14:09 GMT
    # gpg:                using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
    # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full]
    # Primary key fingerprint: FAAB E75E 1291 7221 DCFD  6BB2 E3E3 2C2C DEAD C0DE
    
    * remotes/philmd-gitlab/tags/edk2-next-20200121:
      gitlab-ci.yml: Add jobs to build EDK2 firmware binaries
      roms/edk2-funcs: Force softfloat ARM toolchain prefix on Debian
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  2. gitlab-ci.yml: Add jobs to build EDK2 firmware binaries

    philmd committed Jan 3, 2020
    Add two GitLab job to build the EDK2 firmware binaries.
    
    The first job build a Docker image with the packages requisite
    to build EDK2, and store this image in the GitLab registry.
    The second job pull the image from the registry and build the
    EDK2 firmware binaries.
    
    The docker image is only rebuilt if the GitLab YAML or the
    Dockerfile is updated.
    The second job is only built when the roms/edk2/ submodule is
    updated, when a git-ref starts with 'edk2' or when the last
    commit contains 'EDK2'. The files generated are archived in
    the artifacts.zip file.
    
    With edk2-stable201905, it took 2 minutes 52 seconds to build
    the docker image, and 36 minutes 28 seconds to generate the
    artifacts.zip with the firmware binaries (filesize: 10MiB).
    
    See: https://gitlab.com/philmd/qemu/pipelines/107553178
    
    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
    Acked-by: Thomas Huth <thuth@redhat.com>
    Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
  3. roms/edk2-funcs: Force softfloat ARM toolchain prefix on Debian

    philmd committed Dec 5, 2019
    The Debian (based) distributions currently provides 2 ARM
    toolchains, documented as [1]:
    
    * The ARM EABI (armel) port targets a range of older 32-bit ARM
      devices, particularly those used in NAS hardware and a variety
      of *plug computers.
    * The newer ARM hard-float (armhf) port supports newer, more
      powerful 32-bit devices using version 7 of the ARM architecture
      specification.
    
    For various reasons documented in [2], the EDK2 project suggests
    to use the softfloat toolchain (named 'armel' by Debian).
    
    Force the softfloat cross toolchain prefix on Debian distributions.
    
    [1] https://www.debian.org/ports/arm/#status
    [2] tianocore/edk2@41203b9
    
    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
    Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
  4. Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-5.0-pull-r…

    pm215 committed Jan 21, 2020
    …equest' into staging
    
    Fix m68k single-stepping with remote gdb
    
    # gpg: Signature made Tue 21 Jan 2020 12:21:12 GMT
    # gpg:                using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C
    # gpg:                issuer "laurent@vivier.eu"
    # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full]
    # gpg:                 aka "Laurent Vivier <laurent@vivier.eu>" [full]
    # gpg:                 aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full]
    # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F  5173 F30C 38BD 3F2F BE3C
    
    * remotes/vivier/tags/m68k-for-5.0-pull-request:
      m68k: Fix regression causing Single-Step via GDB/RSP to not single step
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  5. m68k: Fix regression causing Single-Step via GDB/RSP to not single step

    vivier committed Jan 16, 2020
    A regression that was introduced, with the refactor to TranslatorOps,
    drops two lines that update the PC when single-stepping is being performed.
    
    Fixes: 11ab74b ("target/m68k: Convert to TranslatorOps")
    Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com>
    Suggested-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com>
    Suggested-by: Richard Henderson <richard.henderson@linaro.org>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Signed-off-by: Laurent Vivier <laurent@vivier.eu>
    Message-Id: <20200116165454.2076265-1-laurent@vivier.eu>
  6. Makefile: add missing mkdir MANUAL_BUILDDIR

    Stefan Hajnoczi authored and pm215 committed Jan 20, 2020
    The MANUAL_BUILDDIR directory is automatically created by sphinx-build
    for the other targets.  The index.html target does not use sphinx-build
    so we must manually create the directory to avoid the following error:
    
      GEN     docs/built/index.html
      /bin/sh: docs/built/index.html: No such file or directory
    
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-id: 20200120163400.603449-1-stefanha@redhat.com
    Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commits on Jan 20, 2020
  1. Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-01-20' …

    pm215 committed Jan 20, 2020
    …into staging
    
    Assorted fixes and cleanups.
    v2: - fix 32-bit build
    
    # gpg: Signature made Mon 20 Jan 2020 14:14:11 GMT
    # gpg:                using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6
    # gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full]
    # gpg:                 aka "Gregory Kurz <gregory.kurz@free.fr>" [full]
    # gpg:                 aka "[jpeg image of size 3330]" [full]
    # Primary key fingerprint: B482 8BAF 9431 40CE F2A3  4910 71D4 D5E5 822F 73D6
    
    * remotes/gkurz/tags/9p-next-2020-01-20:
      9pfs/9p.c: remove unneeded labels
      virtfs-proxy-helper.c: remove 'err_out' label in setugid()
      9p: init_in_iov_from_pdu can truncate the size
      9p: local: always return -1 on error in local_unlinkat_common
      9pfs: local: Fix possible memory leak in local_link()
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  2. 9pfs/9p.c: remove unneeded labels

    danielhb authored and gkurz committed Jan 20, 2020
    'out' label in v9fs_xattr_write() and 'out_nofid' label in
    v9fs_complete_rename() can be replaced by appropriate return
    calls.
    
    CC: Greg Kurz <groug@kaod.org>
    Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
    Acked-by: Greg Kurz <groug@kaod.org>
    Signed-off-by: Greg Kurz <groug@kaod.org>
  3. virtfs-proxy-helper.c: remove 'err_out' label in setugid()

    danielhb authored and gkurz committed Jan 20, 2020
    'err_out' can be removed and be replaced by 'return -errno'
    in its only instance in the function.
    
    CC: Greg Kurz <groug@kaod.org>
    Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
    Acked-by: Greg Kurz <groug@kaod.org>
    Signed-off-by: Greg Kurz <groug@kaod.org>
  4. 9p: init_in_iov_from_pdu can truncate the size

    gkurz committed Jan 20, 2020
    init_in_iov_from_pdu might not be able to allocate the full buffer size
    requested, which comes from the client and could be larger than the
    transport has available at the time of the request. Specifically, this
    can happen with read operations, with the client requesting a read up to
    the max allowed, which might be more than the transport has available at
    the time.
    
    Today the implementation of init_in_iov_from_pdu throws an error, both
    Xen and Virtio.
    
    Instead, change the V9fsTransport interface so that the size becomes a
    pointer and can be limited by the implementation of
    init_in_iov_from_pdu.
    
    Change both the Xen and Virtio implementations to set the size to the
    size of the buffer they managed to allocate, instead of throwing an
    error. However, if the allocated buffer size is less than P9_IOHDRSZ
    (the size of the header) still throw an error as the case is unhandable.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
    CC: groug@kaod.org
    CC: anthony.perard@citrix.com
    CC: roman@zededa.com
    CC: qemu_oss@crudebyte.com
    [groug: fix 32-bit build]
    Signed-off-by: Greg Kurz <groug@kaod.org>
  5. 9p: local: always return -1 on error in local_unlinkat_common

    danielhb authored and gkurz committed Jan 20, 2020
    local_unlinkat_common() is supposed to always return -1 on error.
    This is being done by jumps to the 'err_out' label, which is
    a 'return ret' call, and 'ret' is initialized with -1.
    
    Unfortunately there is a condition in which the function will
    return 0 on error: in a case where flags == AT_REMOVEDIR, 'ret'
    will be 0 when reaching
    
    map_dirfd = openat_dir(...)
    
    And, if map_dirfd == -1 and errno != ENOENT, the existing 'err_out'
    jump will execute 'return ret', when ret is still set to zero
    at that point.
    
    This patch fixes it by changing all 'err_out' labels by
    'return -1' calls, ensuring that the function will always
    return -1 on error conditions. 'ret' can be left unintialized
    since it's now being used just to store the result of 'unlinkat'
    calls.
    
    CC: Greg Kurz <groug@kaod.org>
    Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
    [groug: changed prefix in title to be "9p: local:"]
    Signed-off-by: Greg Kurz <groug@kaod.org>
  6. 9pfs: local: Fix possible memory leak in local_link()

    Jiajun Chen authored and gkurz committed Jan 20, 2020
    There is a possible memory leak while local_link return -1 without free
    odirpath and oname.
    
    Reported-by: Euler Robot <euler.robot@huawei.com>
    Signed-off-by: Jaijun Chen <chenjiajun8@huawei.com>
    Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com>
    Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
    Signed-off-by: Greg Kurz <groug@kaod.org>
  7. qapi: Fix code generation with Python 3.5

    Markus Armbruster authored and pm215 committed Jan 16, 2020
    Recent commit 3e7fb58 "qapi: Fix code generation for empty modules"
    modules" switched QAPISchema.visit() from
    
        for entity in self._entity_list:
    
    effectively to
    
        for mod in self._module_dict.values():
            for entity in mod._entity_list:
    
    Visits in the same order as long as .values() is in insertion order.
    That's the case only for Python 3.6 and later.  Before, it's in some
    arbitrary order, which results in broken generated code.
    
    Fix by making self._module_dict an OrderedDict rather than a dict.
    
    Fixes: 3e7fb58
    Signed-off-by: Markus Armbruster <armbru@redhat.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
    Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
    Tested-by: Thomas Huth <thuth@redhat.com>
    Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
    Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
    Tested-by: Alex Bennée <alex.bennee@linaro.org>
    Message-id: 20200116202558.31473-1-armbru@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  8. Merge remote-tracking branch 'remotes/juanquintela/tags/migration-pul…

    pm215 committed Jan 20, 2020
    …l-pull-request' into staging
    
    Migration pull request
    
    # gpg: Signature made Mon 20 Jan 2020 10:29:53 GMT
    # gpg:                using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723
    # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [full]
    # gpg:                 aka "Juan Quintela <quintela@trasno.org>" [full]
    # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03  4B82 F487 EF18 5872 D723
    
    * remotes/juanquintela/tags/migration-pull-pull-request: (29 commits)
      multifd: Be consistent about using uint64_t
      migration: Support QLIST migration
      apic: Use 32bit APIC ID for migration instance ID
      migration: Change SaveStateEntry.instance_id into uint32_t
      migration: Define VMSTATE_INSTANCE_ID_ANY
      Bug #1829242 correction.
      migration/multifd: fix destroyed mutex access in terminating multifd threads
      migration/multifd: fix nullptr access in terminating multifd threads
      migration/multifd: not use multifd during postcopy
      migration/multifd: clean pages after filling packet
      migration/postcopy: enable compress during postcopy
      migration/postcopy: enable random order target page arrival
      migration/postcopy: set all_zero to true on the first target page
      migration/postcopy: count target page number to decide the place_needed
      migration/postcopy: wait for decompress thread in precopy
      migration/postcopy: reduce memset when it is zero page and matches_target_page_size
      migration/ram: Yield periodically to the main loop
      migration: savevm_state_handler_insert: constant-time element insertion
      migration: add savevm_state_handler_remove()
      misc: use QEMU_IS_ALIGNED
      ...
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
  9. multifd: Be consistent about using uint64_t

    juanquintela committed Jan 14, 2020
    We transmit ram_addr_t always as uint64_t.  Be consistent in its
    use (on 64bit system, it is always uint64_t problem is 32bits).
    
    Signed-off-by: Juan Quintela <quintela@redhat.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
  10. migration: Support QLIST migration

    eauger authored and juanquintela committed Jan 13, 2020
    Support QLIST migration using the same principle as QTAILQ:
    94869d5 ("migration: migrate QTAILQ").
    
    The VMSTATE_QLIST_V macro has the same proto as VMSTATE_QTAILQ_V.
    The change mainly resides in QLIST RAW macros: QLIST_RAW_INSERT_HEAD
    and QLIST_RAW_REVERSE.
    
    Tests also are provided.
    
    Signed-off-by: Eric Auger <eric.auger@redhat.com>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  11. apic: Use 32bit APIC ID for migration instance ID

    xzpeter authored and juanquintela committed Oct 16, 2019
    Migration is silently broken now with x2apic config like this:
    
         -smp 200,maxcpus=288,sockets=2,cores=72,threads=2 \
         -device intel-iommu,intremap=on,eim=on
    
    After migration, the guest kernel could hang at anything, due to
    x2apic bit not migrated correctly in IA32_APIC_BASE on some vcpus, so
    any operations related to x2apic could be broken then (e.g., RDMSR on
    x2apic MSRs could fail because KVM would think that the vcpu hasn't
    enabled x2apic at all).
    
    The issue is that the x2apic bit was never applied correctly for vcpus
    whose ID > 255 when migrate completes, and that's because when we
    migrate APIC we use the APICCommonState.id as instance ID of the
    migration stream, while that's too short for x2apic.
    
    Let's use the newly introduced initial_apic_id for that.
    
    Signed-off-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  12. migration: Change SaveStateEntry.instance_id into uint32_t

    xzpeter authored and juanquintela committed Oct 16, 2019
    It was always used as 32bit, so define it as used to be clear.
    Instead of using -1 as the auto-gen magic value, we switch to
    UINT32_MAX.  We also make sure that we don't auto-gen this value to
    avoid overflowed instance IDs without being noticed.
    
    Suggested-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  13. migration: Define VMSTATE_INSTANCE_ID_ANY

    xzpeter authored and juanquintela committed Oct 16, 2019
    Define the new macro VMSTATE_INSTANCE_ID_ANY for callers who wants to
    auto-generate the vmstate instance ID.  Previously it was hard coded
    as -1 instead of this macro.  It helps to change this default value in
    the follow up patches.  No functional change.
    
    Signed-off-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  14. Bug #1829242 correction.

    nevilad authored and juanquintela committed Jan 10, 2020
    Added type conversions to ram_addr_t before all left shifts of page
    indexes to TARGET_PAGE_BITS, to correct overflows when the page
    address was 4Gb and more.
    
    Signed-off-by: Alexey Romko <nevilad@yahoo.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  15. migration/multifd: fix destroyed mutex access in terminating multifd …

    Jiahui Cen authored and juanquintela committed Oct 23, 2019
    …threads
    
    One multifd will lock all the other multifds' IOChannel mutex to inform them
    to quit by setting p->quit or shutting down p->c. In this senario, if some
    multifds had already been terminated and multifd_load_cleanup/multifd_save_cleanup
    had destroyed their mutex, it could cause destroyed mutex access when trying
    lock their mutex.
    
    Here is the coredump stack:
        #0  0x00007f81a2794437 in raise () from /usr/lib64/libc.so.6
        qemu#1  0x00007f81a2795b28 in abort () from /usr/lib64/libc.so.6
        qemu#2  0x00007f81a278d1b6 in __assert_fail_base () from /usr/lib64/libc.so.6
        qemu#3  0x00007f81a278d262 in __assert_fail () from /usr/lib64/libc.so.6
        qemu#4  0x000055eb1bfadbd3 in qemu_mutex_lock_impl (mutex=0x55eb1e2d1988, file=<optimized out>, line=<optimized out>) at util/qemu-thread-posix.c:64
        qemu#5  0x000055eb1bb4564a in multifd_send_terminate_threads (err=<optimized out>) at migration/ram.c:1015
        qemu#6  0x000055eb1bb4bb7f in multifd_send_thread (opaque=0x55eb1e2d19f8) at migration/ram.c:1171
        qemu#7  0x000055eb1bfad628 in qemu_thread_start (args=0x55eb1e170450) at util/qemu-thread-posix.c:502
        qemu#8  0x00007f81a2b36df5 in start_thread () from /usr/lib64/libpthread.so.0
        qemu#9  0x00007f81a286048d in clone () from /usr/lib64/libc.so.6
    
    To fix it up, let's destroy the mutex after all the other multifd threads had
    been terminated.
    
    Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
    Signed-off-by: Ying Fang <fangying1@huawei.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  16. migration/multifd: fix nullptr access in terminating multifd threads

    Jiahui Cen authored and juanquintela committed Oct 23, 2019
    One multifd channel will shutdown all the other multifd's IOChannel when it
    fails to receive an IOChannel. In this senario, if some multifds had not
    received its IOChannel yet, it would try to shutdown its IOChannel which could
    cause nullptr access at qio_channel_shutdown.
    
    Here is the coredump stack:
        #0  object_get_class (obj=obj@entry=0x0) at qom/object.c:908
        qemu#1  0x00005563fdbb8f4a in qio_channel_shutdown (ioc=0x0, how=QIO_CHANNEL_SHUTDOWN_BOTH, errp=0x0) at io/channel.c:355
        qemu#2  0x00005563fd7b4c5f in multifd_recv_terminate_threads (err=<optimized out>) at migration/ram.c:1280
        qemu#3  0x00005563fd7bc019 in multifd_recv_new_channel (ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce00) at migration/ram.c:1478
        qemu#4  0x00005563fda82177 in migration_ioc_process_incoming (ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce30) at migration/migration.c:605
        qemu#5  0x00005563fda8567d in migration_channel_process_incoming (ioc=0x556400255610) at migration/channel.c:44
        qemu#6  0x00005563fda83ee0 in socket_accept_incoming_migration (listener=0x5563fff6b920, cioc=0x556400255610, opaque=<optimized out>) at migration/socket.c:166
        qemu#7  0x00005563fdbc25cd in qio_net_listener_channel_func (ioc=<optimized out>, condition=<optimized out>, opaque=<optimized out>) at io/net-listener.c:54
        qemu#8  0x00007f895b6fe9a9 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
        qemu#9  0x00005563fdc18136 in glib_pollfds_poll () at util/main-loop.c:218
        qemu#10 0x00005563fdc181b5 in os_host_main_loop_wait (timeout=1000000000) at util/main-loop.c:241
        qemu#11 0x00005563fdc183a2 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:517
        qemu#12 0x00005563fd8edb37 in main_loop () at vl.c:1791
        qemu#13 0x00005563fd74fd45 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4473
    
    To fix it up, let's check p->c before calling qio_channel_shutdown.
    
    Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
    Signed-off-by: Ying Fang <fangying1@huawei.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  17. migration/multifd: not use multifd during postcopy

    Wei Yang authored and juanquintela committed Oct 25, 2019
    We don't support multifd during postcopy, but user still could enable
    both multifd and postcopy. This leads to migration failure.
    
    Skip multifd during postcopy.
    
    Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  18. migration/multifd: clean pages after filling packet

    Wei Yang authored and juanquintela committed Oct 25, 2019
    This is a preparation for the next patch:
    
        not use multifd during postcopy.
    
    Without enabling postcopy, everything looks good. While after enabling
    postcopy, migration may fail even not use multifd during postcopy. The
    reason is the pages is not properly cleared and *old* target page will
    continue to be transferred.
    
    After clean pages, migration succeeds.
    
    Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  19. migration/postcopy: enable compress during postcopy

    Wei Yang authored and juanquintela committed Nov 7, 2019
    postcopy requires to place a whole host page, while migration thread
    migrate memory in target page size. This makes postcopy need to collect
    all target pages in one host page before placing via userfaultfd.
    
    To enable compress during postcopy, there are two problems to solve:
    
        1. Random order for target page arrival
        2. Target pages in one host page arrives without interrupt by target
           page from other host page
    
    The first one is handled by previous cleanup patch.
    
    This patch handles the second one by:
    
        1. Flush compress thread for each host page
        2. Wait for decompress thread for before placing host page
    
    Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  20. migration/postcopy: enable random order target page arrival

    Wei Yang authored and juanquintela committed Nov 7, 2019
    After using number of target page received to track one host page, we
    could have the capability to handle random order target page arrival in
    one host page.
    
    This is a preparation for enabling compress during postcopy.
    
    Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  21. migration/postcopy: set all_zero to true on the first target page

    Wei Yang authored and juanquintela committed Nov 7, 2019
    For the first target page, all_zero is set to true for this round check.
    
    After target_pages introduced, we could leverage this variable instead
    of checking the address offset.
    
    Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  22. migration/postcopy: count target page number to decide the place_needed

    Wei Yang authored and juanquintela committed Nov 7, 2019
    In postcopy, it requires to place whole host page instead of target
    page.
    
    Currently, it relies on the page offset to decide whether this is the
    last target page. We also can count the target page number during the
    iteration. When the number of target page equals
    (host page size / target page size), this means it is the last target
    page in the host page.
    
    This is a preparation for non-ordered target page transmission.
    
    Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  23. migration/postcopy: wait for decompress thread in precopy

    Wei Yang authored and juanquintela committed Nov 7, 2019
    Compress is not supported with postcopy, it is safe to wait for
    decompress thread just in precopy.
    
    This is a preparation for later patch.
    
    Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  24. migration/postcopy: reduce memset when it is zero page and matches_ta…

    Wei Yang authored and juanquintela committed Nov 7, 2019
    …rget_page_size
    
    In this case, page_buffer content would not be used.
    
    Skip this to save some time.
    
    Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  25. migration/ram: Yield periodically to the main loop

    Yury Kotov authored and juanquintela committed Nov 25, 2019
    Usually, incoming migration coroutine yields to the main loop
    while its IO-channel is waiting for data to receive. But there is a case
    when RAM migration and data receive have the same speed: VM with huge
    zeroed RAM. In this case, IO-channel won't read and thus the main loop
    is stuck and for instance, it doesn't respond to QMP commands.
    
    For this case, yield periodically, but not too often, so as not to
    affect the speed of migration.
    
    Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  26. migration: savevm_state_handler_insert: constant-time element insertion

    Scott Cheloha authored and juanquintela committed Oct 17, 2019
    savevm_state's SaveStateEntry TAILQ is a priority queue.  Priority
    sorting is maintained by searching from head to tail for a suitable
    insertion spot.  Insertion is thus an O(n) operation.
    
    If we instead keep track of the head of each priority's subqueue
    within that larger queue we can reduce this operation to O(1) time.
    
    savevm_state_handler_remove() becomes slightly more complex to
    accomodate these gains: we need to replace the head of a priority's
    subqueue when removing it.
    
    With O(1) insertion, booting VMs with many SaveStateEntry objects is
    more plausible.  For example, a ppc64 VM with maxmem=8T has 40000 such
    objects to insert.
    
    Signed-off-by: Scott Cheloha <cheloha@linux.vnet.ibm.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
  27. migration: add savevm_state_handler_remove()

    Scott Cheloha authored and juanquintela committed Oct 17, 2019
    Create a function to abstract common logic needed when removing a
    SaveStateEntry element from the savevm_state.handlers queue.
    
    For now we just remove the element.  Soon it will involve additional
    cleanup.
    
    Signed-off-by: Scott Cheloha <cheloha@linux.vnet.ibm.com>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Juan Quintela <quintela@redhat.com>
Older
You can’t perform that action at this time.