On Thu, Aug 28, 2014 at 2:35 AM, Mark Rutland [off-list ref] wrote:

On Thu, Aug 28, 2014 at 04:33:31AM +0100, Doug Anderson wrote:

quoted

Hi,

On Wed, Aug 27, 2014 at 7:58 PM, Olof Johansson [off-list ref] wrote:

quoted

On Wed, Aug 27, 2014 at 5:56 PM, Stephen Boyd [off-list ref] wrote:

quoted

On 08/27/14 15:33, Olof Johansson wrote:

quoted

On Wed, Aug 27, 2014 at 3:26 PM, Stephen Boyd [off-list ref] wrote:

quoted

Is there any reason why the virtual counter can't be read? Maybe we're
the hyp and we need to make sure we don't use the virtual timer so that
the guest can use it, but that doesn't have any effect on the usage of
the virtual counter for the clocksource.

There are several cases where virtual is unusable -- in particular it
might not have been configured properly (i.e. the phys/virt offset is
at a bad value).

Any specifics? It would be nice to say so in the commit text so that
others using such devices know they need this patch. I'm guessing the
firmware can't be fixed?

Even if we could change things to use a virtual timer in some cases,
Sonny's patch still fixes a bug.  The code as written right now makes
pretenses about supporting the physical timer, but it doesn't work.
That should be fixed.

The code does support the physical timer. It does not support the
physical counter (and makes no pretenses that it does).

Is there some reason that it should not support it?  It seems like the
two things are highly related.

I had hoped we wouldn't encounter cases where CNTVOFF was hopelessly
ill-configured on a platform, but evidently we have. So we need some
workaround for that.

quoted

quoted

Yeah, there are a few. The big.LITTLE on the Chromebook 2 models have
this issue, due to the A7 cluster having an incorrect offset
programmed. However, arch timers aren't supported on that SoC in the
first place, so it's not a problem in reality.

The other known platform is rk3288. It has products out in the wild
where firmware updates are unlikely.

One other reason is that (I'm told) that the virtual offset is lost in
certain power down conditions (powering down a core, going into S3,
etc).  When we power back up the offset is effectively reset to a
random value.  That means we need something to reprogram the virtual
timer offset whenever we power things back up.

If we've got a hypervisor then the hypervisor will definitely be
involved in powering things back up and it can reset the virtual
offset.  ...but forcing systems to implement a hypervisor (or somehow
adding an interface for the kernel to call back into firmware) is a
huge effort and it means more hard-to-update code sitting in firmware.

Not if you boot Linux at hyp, as we've recommended for this precise
reason. That doesn't fix other things like CNTFRQ if the secure
initialisation doesn't poke that, however.

That's interesting, we could look into that.

Thanks,
Mark.