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 >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
