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, Thomas Gleixner wrote:
>> > > > On T
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, Thomas Gleixner wrote:
> > > > On Thu, Aug 01 2024 at 16:14, Michael Kelley wrote:
> > > > > I don'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 convenient way to test my sequence on KVM.
> >
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 convenient way to test my sequence on KVM.
> >
> > But still fails in KVM
>
> By KVM you mean the in-kernel one tha
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, Aug 02 2024 at 12:04, David Woodhouse wrote:
> On Fri, 2024-08-02 at 12:49 +0200, Thomas Gleixner wrote:
>> So fine, we can go with the patch from Li, but the changelog needs a
>> rewrite and the code want's a big fat comment.
>
> Nah, it wants to be MODE, COUNT, COUNT, MODE to handle all k
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
> > > tedious to stop :)
> >
> > My reading o
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
>> tedious to stop :)
>
> My reading of the data sheet definitely suggests that it *shouldn't*
> be.
>
> Mode 0
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 cowardice on the basis that it doesn't *
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 count in progress, writing a new LSB before the
> >
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 implementation is still toggling the IRQ p
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 implementation is still toggling the IRQ pin; in that case
>> > it's only a few irrelevant transistor
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 (!use_pit()) {
>> +if (!hypervisor_is_t
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 (!use_pit()) {
> + if (!hypervisor_is_type(X86_HYPER_NATIVE)) {
> + /*
> +
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 f
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 t
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 progress, writing a new LSB before the
> > >
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 progress, writing a new LSB before the
>> counter has counted down to 0 and rolled over to h, WILL stop
>>
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 h, WILL stop
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 sequence does:
>
> outb_p(0x30, PIT_MODE);
> outb_p(0xff, PIT_CH0)
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)
> > >
> > > outb_p(
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: Thomas Gleixner Sent: Thursday, August 1, 2024 7:21
AM
>
> 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) {
> > -
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 5:15 PM
> > > > > >
> > > > > > Zeroing the counter register in pit_shutdow
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) {
> - outb_p(0, PIT_CH0);
> - outb_p(0, PIT_CH0);
> -
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,
> >
27 matches
Mail list logo
