All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Juan Jose Quintela Carreira <quintela@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Bulent Abali <abali@us.ibm.com>,
	"mrhines@us.ibm.com" <mrhines@us.ibm.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Chegu Vinod <chegu_vinod@hp.com>
Subject: Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support
Date: Fri, 14 Jun 2013 02:25:39 -0400	[thread overview]
Message-ID: <51BAB763.1040501@linux.vnet.ibm.com> (raw)
In-Reply-To: <51BA3C4F.9030701@redhat.com>

On 06/13/2013 05:40 PM, Paolo Bonzini wrote:
> Il 13/06/2013 17:17, Michael R. Hines ha scritto:
>> On 06/13/2013 04:06 PM, Paolo Bonzini wrote:
>>> Regarding the timestamp problem, it should be fixed in the RDMA code.
>>> You did find a bug, but xyz_start_outgoing_migration should be
>>> asynchronous and the pinning should happen in the setup phase.  This is
>>> because the setup phase is already running outside the big QEMU lock and
>>> the guest would not be frozen.
>> I think you misunderstood the symptom. The pinning is *already*
>> happening in the setup phase (xyz_start_outgoing_migration), not
>> inside the the migration_thread().
> I was referring to ram_control_before_iterate(f, RAM_CONTROL_SETUP).
> Even better, that would be a good reason to remove the
>
> +     * Please leave in place. These calls generate reserved messages in
> +     * the RDMA protocol in order to pre-register RDMA memory in the
> +     * future before the bulk round begins.
>
> comment that I don't like. :)
>
> xyz_start_outgoing_migration is the connect phase if you want to give it
> a name.
>
> The connect phase runs with the big QEMU lock taken, so any interrupt
> will freeze VCPUs until the pinning ends.

Excellent suggestions. I've re-submitted the patch already with these 
modifications as v8.

Thanks, Paolo.

>
> Juan, are you going to pick this up, or should Anthony do it?  (Michael:
> in any case, do not send a pull request yourself).

Understood =).

  reply	other threads:[~2013-06-14  6:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-10 16:03 [Qemu-devel] [PATCH v7 00/12] rdma: migration support mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 01/12] rdma: add documentation mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 02/12] rdma: introduce qemu_update_position() mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 03/12] rdma: export yield_until_fd_readable() mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 04/12] rdma: export throughput w/ MigrationStats QMP mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 05/12] rdma: introduce qemu_file_mode_is_not_valid() mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 06/12] rdma: export qemu_fflush() mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 07/12] rdma: introduce ram_handle_compressed() mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 08/12] rdma: introduce qemu_ram_foreach_block() mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 09/12] rdma: new QEMUFileOps hooks mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 10/12] rdma: introduce capability x-rdma-pin-all mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 11/12] rdma: core logic mrhines
2013-06-10 16:03 ` [Qemu-devel] [PATCH v7 12/12] rdma: send pc.ram mrhines
     [not found] ` <4168C988EBDF2141B4E0B6475B6A73D10CE2AAC1@G6W2488.americas.hpqcorp.net>
     [not found]   ` <51B60ABA.2070401@linux.vnet.ibm.com>
     [not found]     ` <4168C988EBDF2141B4E0B6475B6A73D10CE2BAE7@G6W2488.americas.hpqcorp.net>
     [not found]       ` <51B7B652.3070905@linux.vnet.ibm.com>
     [not found]         ` <51B85EE5.1050702@hp.com>
     [not found]           ` <51B868B3.9090607@linux.vnet.ibm.com>
     [not found]             ` <51B9A614.2050101@hp.com>
     [not found]               ` <51B9BFCA.4050008@linux.vnet.ibm.com>
     [not found]                 ` <51B9CE2E.5080504@hp.com>
2013-06-13 14:45                   ` [Qemu-devel] [PATCH v7 00/12] rdma: migration support Michael R. Hines
     [not found]               ` <51B9C2D6.30000@linux.vnet.ibm.com>
     [not found]                 ` <51B9D6A8.9070007@hp.com>
2013-06-13 14:55                   ` Michael R. Hines
2013-06-13 20:06                     ` Paolo Bonzini
2013-06-13 21:17                       ` Michael R. Hines
2013-06-13 21:40                         ` Paolo Bonzini
2013-06-14  6:25                           ` Michael R. Hines [this message]
2013-06-14  6:30                         ` [Qemu-devel] RDMA: please pull and re-test freezing fixes Michael R. Hines
2013-06-14 20:38                           ` Michael R. Hines
2013-06-15 22:50                             ` Chegu Vinod
2013-06-16  4:13                             ` Michael R. Hines

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=51BAB763.1040501@linux.vnet.ibm.com \
    --to=mrhines@linux.vnet.ibm.com \
    --cc=abali@us.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=chegu_vinod@hp.com \
    --cc=mrhines@us.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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.