From: Andrew Jones <drjones@redhat.com>
To: "Jaggi, Manish" <Manish.Jaggi@cavium.com>
Cc: Juan Quintela <quintela@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Auger Eric <eric.auger@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
"peter.maydell@linaro.org qemu-devel@nongnu.org"
<qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Query] Live Migration between machines with different processor ids
Date: Tue, 4 Sep 2018 11:54:02 +0200 [thread overview]
Message-ID: <20180904095402.izdnqag3xak3mgsb@kamzik.brq.redhat.com> (raw)
In-Reply-To: <1604D594-E6D4-48BB-A270-F7CF1092978B@caviumnetworks.com>
On Tue, Sep 04, 2018 at 09:16:58AM +0000, Jaggi, Manish wrote:
> > On 31-Aug-2018, at 4:41 PM, Andrew Jones <drjones@redhat.com> wrote:
> > I think the sequence should look something like this:
> >
> > 1) Guest running on Host A with processor a
> > 2) Stop guest and save its state for migration
> > 3) Migrate guest to Host B with processor b (b is "close enough" to a)
> > 4) Restore guest state after migration
> > If guest is running with '-cpu host'
> > 4.a) Inform KVM of any configuration that impacts invariant registers
> > 4.b) Update the guest's view of all invariant registers to match the
> > host
> > EndIf
> > 5) Run guest
> >
> > 4.a and 4.b require new code both in QEMU and KVM. 4.a may require a new
> > KVM API, unless the existing API can be leveraged.
> >
> > The definition of "close enough" is left to the users and/or higher layers
> > of the Virt stack.
> >
>
> Thanks for detailing the sequence.
> I got another comment from Juan and David which is not to use -cpu host, see below
>
> "I really think that the right approach here is not using -cpu host. You
> do the full work, create a model as David says, and be sure that you car
> run that model on both cpus. It is a lot of work, but it is the only
> way to make sure that this is going to work long term.”
>
> Not using -cpu host is orthogonal to the sequence we have been discussing in this thread.
> Use something like -cpu cortex-a57 (this however does not work so far)
> This would avoid close-enough definition, but would need substantial work.
>
> So which approach should be taken here, whats your take...
>
Inventing a base-AArch64 cpu model that can then be extended with optional
features is a nice way to extend the migratability of a guest, however
it's hard to do because of errata. Since errata workarounds are enabled
per MIDR, then we'd need to invent our own MIDR and also some way to
communicate which errata we want to enable, possibly through some paravirt
mechanism or through some implementation defined system registers that
KVM would need to reserve and define.
That's not just a ton of work for the entire virt stack (not just KVM and
QEMU, but also all the layers above), but it's possible that it won't be
useful in the end anyway. There's risk that enabling just one erratum
workaround would restrict the guest to hosts of the exact same type
anyway. For each erratum that needs to be enabled, the probability of
enabling an incompatible one goes up, so it may not be likely to do much
better than '-cpu host' in the end. I'm afraid that until errata are
primarily showing up in optional CPU features that can simply be disabled
for the workaround, that we're stuck with '-cpu host'. I'd be happy to
discuss it more though.
In short, I'd go with the proposal above, for now, with possibly one
change. libvirt folk (Andrea Bolognani and Pino Toscano) suggest that
the guest invariant register updating on the destination host only be
done if the user opts-in to it. This is because right now if a user
tries to migrate to a host that is not 100% identical the migration
will fail, which makes the "mistake" clear. If we silently change the
behavior to allow it, then what could have been a mistake, because
the hosts aren't actually "close enough", may go unnoticed. I'm not
100% sure we need another user opt-in flag to be set, though, as I
think the '-cpu host' indicates the user expects the VCPU to look
like the host CPU, and even after migration that expectation should be
met. Simply, users that migrate '-cpu host' VMs need to know what they're
doing.
Thanks,
drew
next prev parent reply other threads:[~2018-09-04 9:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-21 6:39 [Qemu-devel] Live Migration between machines with different processor ids Mjaggi Oss
2018-08-23 11:18 ` [Qemu-devel] [Query] " Jaggi, Manish
2018-08-23 14:29 ` Juan Quintela
2018-08-24 9:24 ` Jaggi, Manish
2018-08-28 17:27 ` Dr. David Alan Gilbert
2018-08-29 12:40 ` Jaggi, Manish
2018-08-29 13:16 ` Andrew Jones
2018-08-31 9:52 ` Jaggi, Manish
2018-08-31 11:11 ` Andrew Jones
2018-09-04 9:16 ` Jaggi, Manish
2018-09-04 9:54 ` Andrew Jones [this message]
2018-09-04 10:27 ` Juan Quintela
2018-09-04 10:32 ` Dr. David Alan Gilbert
2018-09-04 12:17 ` Peter Maydell
2018-09-05 11:46 ` Jaggi, Manish
2018-09-05 12:20 ` Andrew Jones
2018-09-05 12:42 ` Jaggi, Manish
2018-09-05 13:17 ` Andrew Jones
2018-08-29 13:58 ` Dr. David Alan Gilbert
2018-08-31 9:41 ` Juan Quintela
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=20180904095402.izdnqag3xak3mgsb@kamzik.brq.redhat.com \
--to=drjones@redhat.com \
--cc=Manish.Jaggi@cavium.com \
--cc=aliguori@us.ibm.com \
--cc=dgilbert@redhat.com \
--cc=eric.auger@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.