All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alexander Graf <agraf@suse.de>, Peter Maydell <peter.maydell@linaro.org>
Cc: "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Add @cpu_dt_id into migration stream
Date: Fri, 11 Apr 2014 00:35:47 +1000	[thread overview]
Message-ID: <5346AC43.2060600@ozlabs.ru> (raw)
In-Reply-To: <53468A29.50404@suse.de>

On 04/10/2014 10:10 PM, Alexander Graf wrote:
> 
> On 08.04.14 03:26, Alexey Kardashevskiy wrote:
>> On 03/28/2014 12:07 AM, Alexey Kardashevskiy wrote:
>>> On 03/27/2014 11:57 PM, Peter Maydell wrote:
>>>> On 27 March 2014 12:49, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>> On 03/27/2014 11:37 PM, Andreas Färber wrote:
>>>>>> Am 27.03.2014 03:41, schrieb Alexey Kardashevskiy:
>>>>>>> This should prevent the destination guest from misbehaving when
>>>>>>> the threads number is different in "-smp" command.
>>>>>> Sorry, I don't understand. When migrating, surely -smp needs to be the
>>>>>> same on source and destination, so how can they differ?
>>>>>
>>>>> The idea is that "-smp" does not migrate and if we run source and
>>>>> destination guests with different numbers in -smp, we end up with weird
>>>>> machine
>>>> Yes, so don't do that. As I understand it:
>>>>   (1) if you don't run QEMU with the exact same command line
>>>>       and config at both ends then migration won't work
>>>>   (2) we don't guarantee to detect and cleanly fail if you
>>>>       don't do (1)
>>>>
>>>> It would probably be nice if we did detect config mismatches,
>>> Yep, we do not send the device tree (as libvirt does). Pure command line
>>> matching won't work.
>>>
>>>> but that seems to me like a problem we should be addressing
>>>> more globally than just for one particular config item for
>>>> one particular target...
>>
>> Ok. So. Let's assume I want to implement migration of "-smp" parameters.
>> What would be the correct way of doing this in terms of the current QOM
>> principles? Thanks.
> 
> You don't. The migration protocol doesn't migrate configuration. If you
> want to start to transfer VM configuration (which I'd be all in for), do it
> properly and transfer _all_ configuration.


Then what is the purpose of many, many VMSTATE_.*_EQUAL?

And I do not want to send configuration by the proposed patch, I want to
make sure that the new guest is able to continue. Why exactly is this bad?


-- 
Alexey

  reply	other threads:[~2014-04-10 14:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27  2:41 [Qemu-devel] [PATCH] target-ppc: Add @cpu_dt_id into migration stream Alexey Kardashevskiy
2014-03-27 12:37 ` Andreas Färber
2014-03-27 12:49   ` Alexey Kardashevskiy
2014-03-27 12:57     ` Peter Maydell
2014-03-27 13:07       ` Alexey Kardashevskiy
2014-04-08  1:26         ` Alexey Kardashevskiy
2014-04-10 12:10           ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-04-10 14:35             ` Alexey Kardashevskiy [this message]
2014-04-10 14:41               ` Alexander Graf
2014-04-10 14:44                 ` Alexey Kardashevskiy
2014-04-10 14:49               ` Peter Maydell
2014-04-10 15:11                 ` Alexey Kardashevskiy

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=5346AC43.2060600@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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.