All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: aik@ozlabs.ru, agraf@suse.de, qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC 0/4] target-ppc: handle KVM timebase migration
Date: Fri, 15 Apr 2016 15:27:04 +1000	[thread overview]
Message-ID: <20160415052704.GO18218@voom.redhat.com> (raw)
In-Reply-To: <1460042594-8056-1-git-send-email-mark.cave-ayland@ilande.co.uk>

[-- Attachment #1: Type: text/plain, Size: 3515 bytes --]

On Thu, Apr 07, 2016 at 04:23:10PM +0100, Mark Cave-Ayland wrote:
> This RFC series follows on from discussions in the "Migrating decrementer"
> thread relating to handling migration of the timebase and decrementer
> registers for both TCG and KVM. The aim is to provide a consistent virtual
> clock when migrating PPC machines TCG-TCG (already handled) and
> KVM-KVM with both paused and live VMs in a unified manner for all PPC
> machine types.
> 
> The existing code to handle timebase migration on PPC has a few issues:
> 
> 1) It uses cpu_get_host_ticks() which doesn't work correctly on TCG with
> different host architectures

Yeah, that's just wrong.  We should be using qemu_clock_get_ns()
instead.

> 2) tb_offset is calculated from the difference in the host clock between
> source and destination. Thus if the guest is paused then the resulting
> offset is calculated incorrectly since the host clock still runs, regardless
> of the state of the virtual clock.
> 
> 3) Due to a typo in the existing implementation (MIN instead of MAX) then
> guest_tb never takes migration_duration_tb into account

The statement above is not correct.  The problem is not MIN vs. MAX.
The problem is that it was assuming a 1s limit on downtime during
migration which is Just Plain Wrong - especialy in the case where it's
actually a savevm / restore rather than a live migration.

Having a long downtime shouldn't break the guest's timebase sync with
realtime.

> Patches 1-2 introduce a new PPCMachineClass and derive all the PPC machine
> classes from it, not dissimilar to x86's PCMachineClass.
> 
> Patch 3 adds a VM state change hook into PCMachineClass and updates the
> tb_offset from the host when the machine (re)starts as discussed in the
> thread. Note that it may be possible to add the hook to specific machine
> types, however using PPCMachineClass allows all PPC machines to pick up
> this functionality automatically.
> 
> Patch 4 temporarily disables the existing timebase migration code to allow
> testing.
> 
> Note that this has only been compile-tested on x86 as I have no KVM PPC
> hardware and so it's really an RFC to determine whether this approach can
> work, and to invite testing and discussion from existing KVM PPC users.
> 
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> 
> 
> Mark Cave-Ayland (4):
>   target-ppc: introduce PPCMachineClass and PPCMachineState
>   target-ppc: derive all PPC machine classes to have PPCMachineClass as
>     their superclass
>   target-ppc: synchronise tb_offset with KVM host on machine start
>   target-ppc: hack to remove existing timebase migration code for
>     testing
> 
>  hw/ppc/e500plat.c       |    7 +++-
>  hw/ppc/mac_newworld.c   |   17 ++------
>  hw/ppc/mac_oldworld.c   |    6 ++-
>  hw/ppc/mpc8544ds.c      |    7 +++-
>  hw/ppc/ppc.c            |  100 +++++++++++++++++++++++++++++------------------
>  hw/ppc/ppc405_boards.c  |   28 +++----------
>  hw/ppc/ppc440_bamboo.c  |    6 ++-
>  hw/ppc/prep.c           |    6 ++-
>  hw/ppc/spapr.c          |    2 +-
>  hw/ppc/virtex_ml507.c   |    6 ++-
>  include/hw/ppc/ppc.h    |   35 +++++++++++++++++
>  include/qemu/typedefs.h |    2 +
>  12 files changed, 135 insertions(+), 87 deletions(-)
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      parent reply	other threads:[~2016-04-15  8:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-07 15:23 [Qemu-devel] [RFC 0/4] target-ppc: handle KVM timebase migration Mark Cave-Ayland
2016-04-07 15:23 ` [Qemu-devel] [RFC 1/4] target-ppc: introduce PPCMachineClass and PPCMachineState Mark Cave-Ayland
2016-04-15  5:13   ` David Gibson
2016-04-07 15:23 ` [Qemu-devel] [RFC 2/4] target-ppc: derive all PPC machine classes to have PPCMachineClass as their superclass Mark Cave-Ayland
2016-04-15  5:17   ` David Gibson
2016-04-07 15:23 ` [Qemu-devel] [RFC 3/4] target-ppc: synchronise tb_offset with KVM host on machine start Mark Cave-Ayland
2016-04-15  5:23   ` David Gibson
2016-04-07 15:23 ` [Qemu-devel] [RFC 4/4] target-ppc: hack to remove existing timebase migration code for testing Mark Cave-Ayland
2016-04-15  5:27 ` David Gibson [this message]

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=20160415052704.GO18218@voom.redhat.com \
    --to=david@gibson.dropbear.id.au \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=mark.cave-ayland@ilande.co.uk \
    --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.