[Qemu-devel] [PATCH v6 27/28] migration/qmp: add command migrate-pause

It pauses an ongoing migration. Currently it only supports postcopy. Note that this command will work on either side of the migration. Basically when we trigger this on one side, it'll interrupt the other side as well since the other side will get notified on the disconnect event. However, it's

Re: [Qemu-devel] [PATCH 2/2] scsi: add block job opblockers for scsi-block

On 08/02/2018 02:35, Fam Zheng wrote: > On Wed, 02/07 17:36, Paolo Bonzini wrote: >> @@ -2626,6 +2656,36 @@ static void scsi_block_realize(SCSIDevice *dev, Error >> **errp) >> >> scsi_realize(>qdev, errp); >> scsi_generic_read_device_identification(>qdev); >> + >> +/* For op

[Qemu-devel] [PATCH v6 26/28] hmp/migration: add migrate_recover command

Sister command to migrate-recover in QMP. Signed-off-by: Peter Xu --- hmp-commands.hx | 13 + hmp.c | 10 ++ hmp.h | 1 + 3 files changed, 24 insertions(+) diff --git a/hmp-commands.hx b/hmp-commands.hx index 28ed5a7a13..7563f3eaa0

[Qemu-devel] [PATCH v6 14/28] migration: wakeup dst ram-load-thread for recover

On the destination side, we cannot wake up all the threads when we got reconnected. The first thing to do is to wake up the main load thread, so that we can continue to receive valid messages from source again and reply when needed. At this point, we switch the destination VM state from

Re: [Qemu-devel] [PATCH v6 00/28] Migration: postcopy failure recovery

On Thu, Feb 08, 2018 at 06:31:04PM +0800, Peter Xu wrote: [...] > 6. On source, manually trigger a "fake network down" using >"migrate-cancel" command: > > {"execute": "migrate_cancel"} > {"return": {}} > > During postcopy, it'll not really cancel the migration, but pause > it. On

[Qemu-devel] [PATCH v6 12/28] migration: rebuild channel on source

This patch detects the "resume" flag of migration command, rebuild the channels only if the flag is set. Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu --- migration/migration.c | 91 +++ 1

[Qemu-devel] [PATCH v6 22/28] migration: final handshake for the resume

Finish the last step to do the final handshake for the recovery. First source sends one MIG_CMD_RESUME to dst, telling that source is ready to resume. Then, dest replies with MIG_RP_MSG_RESUME_ACK to source, telling that dest is ready to resume (after switch to postcopy-active state). When

[Qemu-devel] [PATCH v6 23/28] migration: init dst in migration_object_init too

Though we may not need it, now we init both the src/dst migration objects in migration_object_init() so that even incoming migration object would be thread safe (it was not). Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu ---

[Qemu-devel] [PATCH v6 25/28] qmp/migration: new command migrate-recover

The first allow-oob=true command. It's used on destination side when the postcopy migration is paused and ready for a recovery. After execution, a new migration channel will be established for postcopy to continue. Signed-off-by: Peter Xu --- migration/migration.c | 26

[Qemu-devel] [PATCH v6 09/28] migration: allow fault thread to pause

Allows the fault thread to stop handling page faults temporarily. When network failure happened (and if we expect a recovery afterwards), we should not allow the fault thread to continue sending things to source, instead, it should halt for a while until the connection is rebuilt. When the dest

[Qemu-devel] [PATCH v6 20/28] migration: synchronize dirty bitmap for resume

This patch implements the first part of core RAM resume logic for postcopy. ram_resume_prepare() is provided for the work. When the migration is interrupted by network failure, the dirty bitmap on the source side will be meaningless, because even the dirty bit is cleared, it is still possible

[Qemu-devel] [PATCH v6 16/28] migration: new message MIG_RP_MSG_RECV_BITMAP

Introducing new return path message MIG_RP_MSG_RECV_BITMAP to send received bitmap of ramblock back to source. This is the reply message of MIG_CMD_RECV_BITMAP, it contains not only the header (including the ramblock name), and it was appended with the whole ramblock received bitmap on the

[Qemu-devel] [PATCH v6 11/28] migration: pass MigrationState to migrate_init()

Let the callers take the object, then pass it to migrate_init(). Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu --- migration/migration.c | 7 ++- migration/migration.h | 2 +- migration/savevm.c| 5 - 3 files changed, 7

[Qemu-devel] [PATCH v6 06/28] migration: allow dst vm pause on postcopy

When there is IO error on the incoming channel (e.g., network down), instead of bailing out immediately, we allow the dst vm to switch to the new POSTCOPY_PAUSE state. Currently it is still simple - it waits the new semaphore, until someone poke it for another attempt. One note is that here on

[Qemu-devel] [PATCH v6 19/28] migration: introduce SaveVMHandlers.resume_prepare

This is hook function to be called when a postcopy migration wants to resume from a failure. For each module, it should provide its own recovery logic before we switch to the postcopy-active state. Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu

[Qemu-devel] [PATCH v6 15/28] migration: new cmd MIG_CMD_RECV_BITMAP

Add a new vm command MIG_CMD_RECV_BITMAP to request received bitmap for one ramblock. Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu --- migration/savevm.c | 61 ++ migration/savevm.h |

[Qemu-devel] [PATCH v6 04/28] migration: new postcopy-pause state

Introducing a new state "postcopy-paused", which can be used when the postcopy migration is paused. It is targeted for postcopy network failure recovery. Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu --- migration/migration.c | 2 ++

[Qemu-devel] [PATCH v6 05/28] migration: implement "postcopy-pause" src logic

Now when network down for postcopy, the source side will not fail the migration. Instead we convert the status into this new paused state, and we will try to wait for a rescue in the future. If a recovery is detected, migration_thread() will reset its local variables to prepare for that.

[Qemu-devel] [PATCH v6 10/28] qmp: hmp: add migrate "resume" option

It will be used when we want to resume one paused migration. Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu --- hmp-commands.hx | 7 --- hmp.c | 4 +++- migration/migration.c | 2 +- qapi/migration.json | 5 -

[Qemu-devel] [PATCH v6 13/28] migration: new state "postcopy-recover"

Introducing new migration state "postcopy-recover". If a migration procedure is paused and the connection is rebuilt afterward successfully, we'll switch the source VM state from "postcopy-paused" to the new state "postcopy-recover", then we'll do the resume logic in the migration thread (along

[Qemu-devel] [PATCH v6 00/28] Migration: postcopy failure recovery

Tree is pushed here for better reference and testing (online tree includes monitor OOB series): https://github.com/xzpeter/qemu/tree/postcopy-recovery-support This version added back the migrate-pause command, and let it to be run on either side of migration. Meanwhile, fixed a tricky error

[Qemu-devel] [PATCH v6 02/28] migration: reuse mis->userfault_quit_fd

It was only used for quitting the page fault thread before. Let it be something more useful - now we can use it to notify a "wake" for the page fault thread (for any reason), and it only means "quit" if the fault_thread_quit is set. Since we changed what it does, renaming it to

[Qemu-devel] [PATCH v6 08/28] migration: allow send_rq to fail

We will not allow failures to happen when sending data from destination to source via the return path. However it is possible that there can be errors along the way. This patch allows the migrate_send_rp_message() to return error when it happens, and further extended it to

[Qemu-devel] [PATCH v6 07/28] migration: allow src return path to pause

Let the thread pause for network issues. Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu --- migration/migration.c | 35 +-- migration/migration.h | 1 + migration/trace-events | 2 ++ 3 files changed, 36

[Qemu-devel] [PATCH v6 01/28] migration: better error handling with QEMUFile

If the postcopy down due to some reason, we can always see this on dst: qemu-system-x86_64: RP: Received invalid message 0x length 0x However in most cases that's not the real issue. The problem is that qemu_get_be16() has no way to show whether the returned data is valid or not, and

[Qemu-devel] [PATCH v6 03/28] migration: provide postcopy_fault_thread_notify()

A general helper to notify the fault thread. Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu --- migration/postcopy-ram.c | 35 --- migration/postcopy-ram.h | 2 ++ 2 files changed, 22 insertions(+), 15

Re: [Qemu-devel] [PATCH v4 03/22] RISC-V CPU Core Definition

On Thu, 8 Feb 2018 15:19:13 +1300 Michael Clark wrote: > On Wed, Feb 7, 2018 at 4:03 AM, Igor Mammedov wrote: > > > On Tue, 6 Feb 2018 11:09:56 +1300 > > Michael Clark wrote: > > > > > On Tue, Feb 6, 2018 at 4:04 AM, Igor Mammedov

Re: [Qemu-devel] [PATCH] S390: Expose s390-specific CPU info

On 02/08/2018 11:16 AM, Cornelia Huck wrote: > On Thu, 8 Feb 2018 10:48:08 +0100 > Viktor Mihajlovski wrote: > > [added some cc:s] > >> Presently s390x is the only architecture not exposing specific >> CPU information via QMP query-cpus. Upstream discussion has

Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration

On 2/8/2018 5:51 PM, Igor Mammedov wrote: On Thu, 8 Feb 2018 09:20:45 +0800 "Tan, Jianfeng" wrote: On 2/7/2018 8:06 PM, Igor Mammedov wrote: On Wed, 7 Feb 2018 07:49:58 + "Tan, Jianfeng" wrote: -Original Message- From: Paolo

Re: [Qemu-devel] [PULL 0/1] Ide patches

On 7 February 2018 at 16:33, John Snow wrote: > The following changes since commit 0833df03f4206a6cf416fbb3d380fa95c8e61fba: > > Merge remote-tracking branch > 'remotes/dgilbert/tags/pull-migration-20180206a' into staging (2018-02-07 > 12:07:23 +) > > are available in

Re: [Qemu-devel] [PATCH] S390: Expose s390-specific CPU info

On Thu, 8 Feb 2018 10:48:08 +0100 Viktor Mihajlovski wrote: [added some cc:s] > Presently s390x is the only architecture not exposing specific > CPU information via QMP query-cpus. Upstream discussion has shown > that it could make sense to report the architecture

Re: [Qemu-devel] [PATCH 1/2] qmp: add query-cpus-fast

On 08.02.2018 08:41, Viktor Mihajlovski wrote: > On 07.02.2018 18:50, Luiz Capitulino wrote: >> The query-cpus command has an extremely serious side effect: >> it always interrupt all running vCPUs so that they can run >> ioctl calls. This can cause a huge performance degradation for >> some

Re: [Qemu-devel] [Qemu-block] [PATCH] block: early check for blockers on drive-mirror

On Wed 07 Feb 2018 05:29:20 PM CET, Paolo Bonzini wrote: > Even if an op blocker is present for BLOCK_OP_TYPE_MIRROR_SOURCE, > it is checked a bit late and the result is that the target is > created even if drive-mirror subsequently fails. Add an early > check to avoid this. > > Signed-off-by:

[Qemu-devel] Questions regarding how QEMU initializes virtual peripherals

Hello all, I am working with QEMU to simulate VersatilePB board. I am trying to understand how QEMU initialize the virtual peripherals (e.g. UART, vectored Interrupt controller .. etc). When I traced the code, I found a function called "object_init_with_type" in object.c, in which the function

[Qemu-devel] [PATCH v7] s390x/cpu: expose the guest crash information

This patch is the s390 implementation of guest crash information, similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM property") and the related commits. We will detect several crash reasons, with the "disabled wait" being the most important one, since this is used by all s390

Re: [Qemu-devel] [PATCH RFC 06/21] qapi-gen: New common driver for code and doc generators

Markus Armbruster writes: > Marc-Andre Lureau writes: > >> On Fri, Feb 2, 2018 at 2:03 PM, Markus Armbruster wrote: [...] >>> diff --git a/scripts/qapi2texi.py b/scripts/qapi/doc.py >>> old mode 100755 >>> new mode 100644 >>> similarity

Re: [Qemu-devel] [patch] linux-user/syscall.c: Fix missing break for host_to_target_cmsg

On 2018-02-07 19:27, Laurent Vivier wrote: Le 07/02/2018 à 10:49, no-re...@patchew.org a écrit : Hi, This series failed build test on s390x host. Please find the details below. ... CC aarch64_be-linux-user/linux-user/syscall.o In file included from

Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration

On Thu, 8 Feb 2018 09:20:45 +0800 "Tan, Jianfeng" wrote: > On 2/7/2018 8:06 PM, Igor Mammedov wrote: > > On Wed, 7 Feb 2018 07:49:58 + > > "Tan, Jianfeng" wrote: > > > >>> -Original Message- > >>> From: Paolo Bonzini

[Qemu-devel] [PATCH] S390: Expose s390-specific CPU info

Presently s390x is the only architecture not exposing specific CPU information via QMP query-cpus. Upstream discussion has shown that it could make sense to report the architecture specific CPU state, e.g. to detect that a CPU has been stopped. With this change the output of query-cpus will look

[Qemu-devel] [PATCH] target-i386: adds PV_DEDICATED hint CPUID feature bit

From: Wanpeng Li Add PV_DEDICATED hint cpuid feature bit. Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Eduardo Habkost Signed-off-by: Wanpeng Li --- target/i386/cpu.c | 4

[Qemu-devel] [PATCH v2] spapr: check smp_threads <= vsmt

We ignore silently the value of smp_threads when we set the default VSMT value, and if smp_threads is greater than VSMT kernel is going into trouble later. Fixes: 8904e5a750 ("spapr: Adjust default VSMT value for better migration compatibility") Signed-off-by: Laurent Vivier

Re: [Qemu-devel] [PATCH 2/2] qmp: document query-cpus performance issue

On Wed, Feb 07, 2018 at 12:50:14PM -0500, Luiz Capitulino wrote: > Signed-off-by: Luiz Capitulino > --- > qapi-schema.json | 4 > 1 file changed, 4 insertions(+) > > diff --git a/qapi-schema.json b/qapi-schema.json > index 82d6f12b53..0665a14dba 100644 > ---

Re: [Qemu-devel] [Qemu-ppc] [PATCH] spapr: check smp_threads < vsmt

On 07/02/2018 21:21, Greg Kurz wrote: > On Wed, 7 Feb 2018 17:17:30 +0100 > Laurent Vivier wrote: > >> We ignore silently the value of smp_threads when we set >> the VSMT value, and if smp_threads is greater than VSMT >> kernel is going into trouble later. >> >> Fixes:

[Qemu-devel] [RESEND PATCH] PPC: e500: Fix duplicate kernel load and device tree overlap

This patch fixes an incorrect behavior when the -kernel argument has been specified without -bios. In this case the kernel was loaded twice. At address 32M as a raw image and afterwards by load_elf/load_uimage at the corresponding load address. In this case the region for the device tree and the

Re: [Qemu-devel] [PATCH v6] s390x/cpu: expose the guest crash information

On Wed, 7 Feb 2018 19:15:22 +0100 Christian Borntraeger wrote: > On 02/07/2018 05:58 PM, Cornelia Huck wrote: > > > > >> +## > >> +# @S390CrashReason: > >> +# > >> +# Reason why the CPU is in a crashed state. > >> +# > >> +# @unknown: no crash reason was set > >> +# >

<    1   2   3   4   5