[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [QEMU-PPC] [PATCH 02/13] target/ppc: Work [S]PURR impleme

From: David Gibson
Subject: Re: [Qemu-ppc] [QEMU-PPC] [PATCH 02/13] target/ppc: Work [S]PURR implementation and add HV support
Date: Thu, 9 May 2019 16:45:35 +1000
User-agent: Mutt/1.11.4 (2019-03-13)

On Tue, May 07, 2019 at 11:28:04AM +1000, Suraj Jitindar Singh wrote:
> On Mon, 2019-05-06 at 16:15 +1000, David Gibson wrote:
> > On Fri, May 03, 2019 at 03:53:05PM +1000, Suraj Jitindar Singh wrote:
> > > The Processor Utilisation of Resources Register (PURR) and Scaled
> > > Processor Utilisation of Resources Register (SPURR) provide an
> > > estimate
> > > of the resources used by the thread, present on POWER7 and later
> > > processors.
> > > 
> > > Currently the [S]PURR registers simply count at the rate of the
> > > timebase.
> > > 
> > > Preserve this behaviour but rework the implementation to store an
> > > offset
> > > like the timebase rather than doing the calculation manually. Also
> > > allow
> > > hypervisor write access to the register along with the currently
> > > available read access.
> > > 
> > > Signed-off-by: Suraj Jitindar Singh <address@hidden>
> > 
> > Hm.  How will this affect migration of the PURR and SPURR?
> So as it turns out, the PURR isn't acutually migrated. We rely on the
> fact that the QEMU_CLOCK_VIRTUAL is migrated and that the PURR can
> never change value. Since it just counts at the same rate as the time
> base we get away with it.

Ah, ok.

> For this to work we will need to add PURR, and VTB for the later patch
> which adds it to the migration stream. I suggest me just migrate by
> value meaning the internal representation can infact change in future
> without breaking migration.

Yes, that sounds good, and we even already have a spot for it in the
sprs array.

At first I was thinking we'd need to fiddle about with adjusting it
afterwards to account for the migration downtime (as we do for tb),
but then I realised that it probably makes more sense *not* to count
the migration downtime against purr and spurr, which makes it even
> What this means is that this patch changing the internal representation
> if fine given migration is broken anyway. When I resend this series
> I'll add the purr and vtb to the migration stream.

Ok, sounds good, therefore:

Reviewed-by: David Gibson <address@hidden>

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_!

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]