qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Vivier <lvivier@redhat.com>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	David Gibson <david@gibson.dropbear.id.au>
Cc: aik@ozlabs.ru, qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 4/4] ppc: ensure we update the decrementer value during migration
Date: Wed, 13 Sep 2017 19:58:23 +0200	[thread overview]
Message-ID: <ccacf611-c2e2-9cad-d927-67c0fcaa3ad6@redhat.com> (raw)
In-Reply-To: <03027eb0-6528-22c6-dcc1-d20323399ec9@ilande.co.uk>

On 13/09/2017 19:11, Mark Cave-Ayland wrote:
> On 13/09/17 08:12, David Gibson wrote:
> 
>> This is subtly incorrect.  It sets the DECR on load to exactly the
>> value that was saved.  That effectively means that the DECR is frozen
>> for the migration downtime, which probably isn't what we want.
>>
>> Instead we need to save the DECR as an offset from the timebase, and
>> restore it relative to the (downtime adjusted) timebase on the
>> destination.
>>
>> The complication with that is that the timebase is generally migrated
>> at the machine level, not the cpu level: the timebase is generally
>> synchronized between cpus in the machine, and migrating it at the
>> individual cpu could break that.  Which means we probably need a
>> machine level hook to handle the decrementer too, even though it
>> logically *is* per-cpu, because otherwise we'll be trying to restore
>> it before the timebase is restored.
> 
> I know that we discussed this in-depth last year, however I was working
> along the lines that Laurent's patch fixed this along the lines of our
> previous discussion:
> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00338.html (and
> indeed Laurent's analysis at
> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01489.html).
> 
> However looking again at the this patch in the context you mentioned
> above, I'm starting to wonder if the right solution now is for the
> machine init function for g3beige/mac99 to do the same as spapr, e.g.
> add cpu_ppc_clock_vm_state_change() as a vm_change_state_handler and
> then add VMSTATE_PPC_TIMEBASE_V from the machine PPCTimeBase into my new
> subsection?
> 
> Laurent, do you think that your state change handler would work
> correctly in this way?

I think all is explained in the second link you have mentioned, it seems 
we don't need a state handler as KVM DECR will no be updated by the migrated value:

hw/ppc/ppc.c

    736 static void __cpu_ppc_store_decr(PowerPCCPU *cpu, uint64_t *nextp,
    737                                  QEMUTimer *timer,
    738                                  void (*raise_excp)(void *),
    739                                  void (*lower_excp)(PowerPCCPU *),
    740                                  uint32_t decr, uint32_t value)
    741 {
...
    749     if (kvm_enabled()) {
    750         /* KVM handles decrementer exceptions, we don't need our own timer */
    751         return;
    752     }
...

But this allows to migrate it for TCG. And it should be correct because in case of TCG I think [need to check] timebase is stopped too (so offset is 0)

David, do you agree with that?

Thanks,
Laurent

  reply	other threads:[~2017-09-13 17:58 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-10 14:37 [Qemu-devel] [PATCH 0/4] ppc: migration fixes for TCG Mark Cave-Ayland
2017-09-10 14:37 ` [Qemu-devel] [PATCH 1/4] ppc: change CPUPPCState access_type from int to uint8_t Mark Cave-Ayland
2017-09-10 16:30   ` Laurent Vivier
2017-09-10 18:00     ` Mark Cave-Ayland
2017-09-10 14:37 ` [Qemu-devel] [PATCH 2/4] ppc: add CPU IRQ state to PPC VMStateDescription Mark Cave-Ayland
2017-09-11  7:50   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2017-09-11  9:30     ` Dr. David Alan Gilbert
2017-09-11 10:48       ` David Gibson
2017-09-11 16:46         ` Mark Cave-Ayland
2017-09-11 17:19           ` Dr. David Alan Gilbert
2017-09-13  7:03             ` David Gibson
2017-09-12 16:21         ` Dr. David Alan Gilbert
2017-09-12 16:41           ` Mark Cave-Ayland
2017-09-12 16:46             ` Mark Cave-Ayland
2017-09-13  2:23               ` Alexey Kardashevskiy
2017-09-13  6:02                 ` David Gibson
2017-09-13 16:44                   ` Mark Cave-Ayland
2017-09-13 17:13                     ` Greg Kurz
2017-09-14  3:48                       ` David Gibson
2017-09-14  3:30                     ` David Gibson
2017-09-10 14:37 ` [Qemu-devel] [PATCH 3/4] ppc: add CPU access_type into the migration stream Mark Cave-Ayland
2017-09-11 10:57   ` David Gibson
2017-09-11 16:52     ` Mark Cave-Ayland
2017-09-13  7:19       ` David Gibson
2017-09-13 17:17         ` Mark Cave-Ayland
2017-09-14  3:54           ` David Gibson
2017-09-10 14:37 ` [Qemu-devel] [PATCH 4/4] ppc: ensure we update the decrementer value during migration Mark Cave-Ayland
2017-09-13  7:12   ` David Gibson
2017-09-13 17:11     ` Mark Cave-Ayland
2017-09-13 17:58       ` Laurent Vivier [this message]
2017-09-14  3:52         ` David Gibson
2017-09-15 12:45           ` Mark Cave-Ayland
2017-09-19  8:36             ` David Gibson

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=ccacf611-c2e2-9cad-d927-67c0fcaa3ad6@redhat.com \
    --to=lvivier@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).