[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNUDXsDaRwczONAu@google.com>
Date: Thu, 10 Aug 2023 08:33:50 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Yikebaer Aizezi <yikebaer61@...il.com>
Subject: Re: [PATCH] KVM: x86: Remove WARN sanity check on hypervisor timer
vs. UNINITIALIZED vCPU
On Thu, Aug 10, 2023, Paolo Bonzini wrote:
> On 8/9/23 01:20, Sean Christopherson wrote:
> > /*
> > - * It should be impossible for the hypervisor timer to be in
> > - * use before KVM has ever run the vCPU.
> > + * Don't bother switching APIC timer emulation from the
> > + * hypervisor timer to the software timer, the only way for the
> > + * APIC timer to be active is if userspace stuffed vCPU state,
> > + * i.e. put the vCPU into a nonsensical state. Only an INIT
> > + * will transition the vCPU out of UNINITIALIZED (without more
> > + * state stuffing from userspace), which will reset the local
> > + * APIC and thus smother the timer anyways, i.e. the APIC timer
>
> "Cancel" is probably more understandable to non-native speakers, though
> undoubtedly less poetic.
I intentionally avoided "cancel" because there is no guaranteed the timer would
actually be canceled (if KVM switched to the software timer). I am/was trying to
call out that even if the timer expires and pends an interrupts, the interrupt
will ultimately be dropped.
Maybe "squashed"?
Powered by blists - more mailing lists