linux-kernel - Re: [PATCH] clockevents/drivers/i8253: Do not zero timer counter in shutdown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bb8c97ea2b3596f605b9e1b27a221a1c64727e59.camel@infradead.org>
Date: Thu, 01 Aug 2024 21:49:15 +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 22:00 +0200, Thomas Gleixner wrote:
> On Thu, Aug 01 2024 at 20:21, David Woodhouse wrote:
> > On Thu, 2024-08-01 at 21:06 +0200, Thomas Gleixner wrote:
> > > Yes. So the sequence should stop KVM from trying to inject
> > > interrupts. Maybe someone fixes it to actually stop fiddling with the
> > > counter too :)
> > 
> > I don't think we care about the counter value, as that's *calculated*
> > on demand when the guest tries to read from it. Or, more to the point,
> > *if* the guest tries to read from it.
> > 
> > As opposed to the interrupt, which is a timer in the VMM which takes a
> > CPU out of guest mode and incurs steal time, just to waggle a pin on
> > the emulated PICs for no good reason.
> 
> Well, if the implementation still arms the timer in the background, then
> it matters because that has to be processed too. I haven't looked at
> that code at all, so what do I know.

It only needs to arm the timer if it needs to send an interrupt.
Otherwise, it's all event-driven from the guest interaction.

> > > > I'm glad I decided to export a function from the clocksource driver and
> > > > just *call* it from pit_timer_init() though. Means we can bikeshed the
> > > > shutdown sequence in *one* place and it isn't duplicated.
> > > 
> > > Right. Though we don't have to make this conditional on hypervisor I
> > > think.
> > 
> > Right, we don't *have* to. I vacillated about that and almost ripped it
> > out before sending the patch, but came down on the side of "hardware is
> > a steaming pile of crap and if I don't *have* to change its behaviour,
> > let's not touch it".
> > 
> > I justify my cowardice on the basis that it doesn't *matter* if a
> > hardware implementation is still toggling the IRQ pin; in that case
> > it's only a few irrelevant transistors which are busy, and it doesn't
> > translate to steal time.
> 
> On real hardware it translates to power...

Perhaps, although I'd guess it's a negligible amount. Still, happy to
be brave and make it unconditional. Want a new version of the patch?


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