Message-ID: <56d3780bc42c98721e15129b7fd53080c4530760.camel@infradead.org>
Date: Fri, 02 Aug 2024 09:07:29 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>, lirongqing@...du.com, 
 seanjc@...gle.com, kys@...rosoft.com, haiyangz@...rosoft.com,
 wei.liu@...nel.org,  decui@...rosoft.com, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com,  x86@...nel.org, linux-hyperv@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clockevents/drivers/i8253: Do not zero timer counter in
 shutdown

On Thu, 2024-08-01 at 20:57 +0200, Thomas Gleixner wrote:
> On Thu, Aug 01 2024 at 19:25, David Woodhouse wrote:
> > On Thu, 2024-08-01 at 18:49 +0100, David Woodhouse wrote:
> > > > The stop sequence is wrong:
> > > > 
> > > >     When there is a count in progress, writing a new LSB before the
> > > >     counter has counted down to 0 and rolled over to FFFFh, WILL stop
> > > >     the counter.  However, if the LSB is loaded AFTER the counter has
> > > >     rolled over to FFFFh, so that an MSB now exists in the counter, then
> > > >     the counter WILL NOT stop.
> > > > 
> > > > The original i8253 datasheet says:
> > > > 
> > > >     1) Write 1st byte stops the current counting
> > > >     2) Write 2nd byte starts the new count
> > > 
> > 
> > It also prefixes that with "Rewriting a counter register during
> > counting results in the following:".
> > 
> > But after you write the MODE register, is it actually supposed to be
> > counting? Just a little further up, under 'Counter Loading', it says:
> 
> It's not counting right out of reset. But once it started counting it's
> tedious to stop :)

My reading of the data sheet definitely suggests that it *shouldn't*
be.


Mode 0 says: "The output will be initially low after the mode set
operation. After the count is loaded into the selected count
register... the counter will count."

Mode 2 says: "When this mode is set, the output will remain high until
after the count register is loaded."

Mode 4 says: "After the mode is set, the output will be high. When the
count is loaded, the counter will begin counting".

All of that strongly hints to me that a *compliant* implementation
(haha) would stop the interrupts (and the count) when the MODE is set.

So writing *only* the mode ought to work, in theory. If the failure
mode is just that a bad implementation takes a little bit more power or
steal time, I wonder if that's what we should do? It's what Hyper-V
wants, it seems. And if other hypervisors/VMMs want to avoid taking
pointless steal time, they can fix their bugs.

(... gets more coffee and starts fixing bugs ...)


> > "The count register is not loaded until the count value is written (one
> > or two bytes, depending on the mode selected by the RL bits), followed
> > by a rising edge and a falling edge of the clock. Any read of the
> > counter prior to that falling clock edge may yield invalid data".
> > 
> > OK, but what *triggers* that invalid state? Given that it explicitly
> > says that a one-byte counter write ends that state, it isn't the first
> > of two bytes. Surely that means that from the time the MODE register is
> > written, any read of the counter may yield invalid data, until the
> > counter is written?
> 
> It seems to keep ticking with the old value.
> 
> > I suspect there are as many implementations (virt and hardware) as
> > there are reasonable interpretations of the spec... and then some.
> 
> Indeed.
> 
> Thanks,
> 
>         tglx
> 


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)

Powered by blists - more mailing lists