On Wed, 2025-02-26 at 18:18 -0800, Sean Christopherson wrote:
> This... snowballed a bit.
>
> The bulk of the changes are in kvmclock and TSC, but pretty much every
> hypervisor's guest-side code gets touched at some point. I am reaonsably
> confident in the correctness of the KVM changes. For a
On 13 August 2024 00:59:40 BST, Sean Christopherson wrote:
>On Fri, Aug 02, 2024, David Woodhouse wrote:
>> On Fri, 2024-08-02 at 07:55 -0700, Sean Christopherson wrote:
>> > On Fri, Aug 02, 2024, David Woodhouse wrote:
>> > > On Thu, 2024-08-01 at 20:54 +0200, Thom
On Fri, 2024-08-02 at 15:44 +, Michael Kelley wrote:
> Did a basic smoke test of this two-patch series on a Hyper-V Gen 1
> VM and on a Gen 2 VM. All looks good and behaves as expected.
>
> On the Gen 1 VM, the PIT is used briefly at boot (takes ~35 interrupts)
> before the Hyper-V synthetic t
On Fri, 2024-08-02 at 07:55 -0700, Sean Christopherson wrote:
> On Fri, Aug 02, 2024, David Woodhouse wrote:
> > On Thu, 2024-08-01 at 20:54 +0200, Thomas Gleixner wrote:
> > > On Thu, Aug 01 2024 at 16:14, Michael Kelley wrote:
> > > > I don't have a conven
From: David Woodhouse
Leaving the PIT interrupt running can cause noticeable steal time for
virtual guests. The VMM generally has a timer which toggles the IRQ input
to the PIC and I/O APIC, which takes CPU time away from the guest. Even
on real hardware, running the counter may use power
From: David Woodhouse
According to the data sheet, writing the MODE register should stop the
counter (and thus the interrupts). This appears to work on real hardware,
at least modern Intel and AMD systems. It should also work on Hyper-V.
However, on some buggy virtual machines the mode change
On Fri, 2024-08-02 at 15:27 +0200, Thomas Gleixner wrote:
> > Top two commits of
> > https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/clocks
> >
> > I'll repost properly if you're happy with them?
>
> Just make the disable unconditional.
Oops, thought I'd done that too. Turns
On Fri, 2024-08-02 at 12:49 +0200, Thomas Gleixner wrote:
> On Fri, Aug 02 2024 at 09:07, David Woodhouse wrote:
> > On Thu, 2024-08-01 at 20:57 +0200, Thomas Gleixner wrote:
> > > It's not counting right out of reset. But once it started counting it's
> > > t
From: David Woodhouse
According to the data sheet, writing the MODE register should stop the
counter (and thus the interrupts). This appears to work on real hardware,
at least modern Intel and AMD systems. It should also work on Hyper-V.
However, on some buggy virtual machines the mode change
On Thu, 2024-08-01 at 22:31 +0100, David Woodhouse wrote:
> On 1 August 2024 22:22:56 BST, Thomas Gleixner wrote:
> > On Thu, Aug 01 2024 at 21:49, David Woodhouse wrote:
> > > On Thu, 2024-08-01 at 22:00 +0200, Thomas Gleixner wrote:
> > > > > I justify my cowar
On Thu, 2024-08-01 at 20:54 +0200, Thomas Gleixner wrote:
> On Thu, Aug 01 2024 at 16:14, Michael Kelley wrote:
> > From: Thomas Gleixner Sent: Thursday, August
> > 1, 2024 7:21 AM
> > FWIW, in Hyper-V guests with the Hyper-V quirk removed, tglx's new
> > sequence does *not* stop the PIT. But this
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 co
On 1 August 2024 22:22:56 BST, Thomas Gleixner wrote:
>On Thu, Aug 01 2024 at 21:49, David Woodhouse wrote:
>> On Thu, 2024-08-01 at 22:00 +0200, Thomas Gleixner wrote:
>>> > I justify my cowardice on the basis that it doesn't *matter* if a
>>> > hardware im
On 1 August 2024 22:07:25 BST, Thomas Gleixner wrote:
>On Thu, Aug 01 2024 at 16:22, David Woodhouse wrote:
>> On Thu, 2024-08-01 at 10:00 +0100, David Woodhouse wrote:
>> bool __init pit_timer_init(void)
>> {
>> -if (!use_pit())
>> +if
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 someon
On Thu, 2024-08-01 at 21:06 +0200, Thomas Gleixner wrote:
> On Thu, Aug 01 2024 at 18:49, David Woodhouse wrote:
> > On Thu, 2024-08-01 at 16:21 +0200, Thomas Gleixner wrote:
> > > The stop sequence is wrong:
> > >
> > > When there is a count in pr
On Thu, 2024-08-01 at 18:49 +0100, David Woodhouse wrote:
> On Thu, 2024-08-01 at 16:21 +0200, Thomas Gleixner wrote:
> > On Tue, Feb 07 2023 at 09:14, lirongq...@baidu.com wrote:
> > > @@ -117,11 +110,6 @@ static int pit_shutdown(struct clock_event_device
> > > *evt)
&
On Thu, 2024-08-01 at 16:21 +0200, Thomas Gleixner wrote:
> On Tue, Feb 07 2023 at 09:14, lirongq...@baidu.com wrote:
> > @@ -117,11 +110,6 @@ static int pit_shutdown(struct clock_event_device *evt)
> >
> > outb_p(0x30, PIT_MODE);
> >
> > - if (i8253_clear_counter_on_shutdown) {
>
From: David Woodhouse
Leaving the PIT interrupt running can cause noticeable steal time for
virtual guests. The VMM generally has a timer which toggles the IRQ input
to the PIC and I/O APIC, which takes CPU time away from the guest.
Make sure it's turned off if it isn't going to be us
On Thu, 2024-08-01 at 10:00 +0100, David Woodhouse wrote:
> >
> >
> >
> > On 2023-02-08 at 01:04:19 +, "Michael Kelley (LINUX)"
> > said:
> > > > From: lirongq...@baidu.com Sent: Monday,
> > > > February 6, 2023
On 2023-02-08 at 01:04:19 +, "Michael Kelley (LINUX)"
said:
> From: lirongq...@baidu.com Sent: Monday, February 6,
> 2023 5:15 PM
> >
> > Zeroing the counter register in pit_shutdown() isn't actually supposed to
> > stop it from counting, will causes the PIT to start running again,
> >
On Thu, 2023-10-19 at 08:40 -0700, Sean Christopherson wrote:
>
> > Normally, it should be up to the hypervisor to tell the guest which
> > clock to use, i.e. if TSC is reliable or not. Let me put my question
> > this way: if TSC on the particular host is good for everything, why
> > does the hype
22 matches
Mail list logo
