From: Wanpeng Li <kernellwp@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Sean Christopherson" <sean.j.christopherson@intel.com>,
LKML <linux-kernel@vger.kernel.org>, kvm <kvm@vger.kernel.org>,
"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH 1/2] KVM: LAPIC: Optimize timer latency consider world switch time
Date: Wed, 12 Jun 2019 17:38:45 +0800 [thread overview]
Message-ID: <CANRm+Czg+5qe3eHrOo-=EbOJM5929Xge+rSwyQoksdkk6PcGzA@mail.gmail.com> (raw)
In-Reply-To: <754c46dd-3ead-2c27-1bcc-52db26418390@redhat.com>
On Fri, 31 May 2019 at 17:01, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 30/05/19 21:36, Sean Christopherson wrote:
> >> +u32 __read_mostly vmentry_lapic_timer_advance_ns = 0;
> >> +module_param(vmentry_lapic_timer_advance_ns, uint, S_IRUGO | S_IWUSR);
> > Hmm, an interesting idea would be to have some way to "lock" this param,
> > e.g. setting bit 0 locks the param. That would allow KVM to calculate the
> > cycles value to avoid the function call and the MUL+DIV. If I'm not
> > mistaken, vcpu->arch.virtual_tsc_khz is set only in kvm_set_tsc_khz().
>
> I would just make it read-only. But I'm afraid we're entering somewhat
> dangerous territory. There is a risk that the guest ends up entering
> the interrupt handler before the TSC deadline has actually expired, and
> there would be no way to know what would happen; even guest hangs are
> possible.
Agreed, do it in v3.
Regards,
Wanpeng Li
prev parent reply other threads:[~2019-06-12 9:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 4:18 [PATCH 1/2] KVM: LAPIC: Optimize timer latency consider world switch time Wanpeng Li
2019-05-23 4:18 ` [PATCH 2/2] KVM: LAPIC: remove the trailing newline used in the fmt parameter of TP_printk Wanpeng Li
2019-05-30 19:36 ` [PATCH 1/2] KVM: LAPIC: Optimize timer latency consider world switch time Sean Christopherson
2019-05-31 6:41 ` Wanpeng Li
2019-05-31 9:01 ` Paolo Bonzini
2019-06-12 9:38 ` Wanpeng Li [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANRm+Czg+5qe3eHrOo-=EbOJM5929Xge+rSwyQoksdkk6PcGzA@mail.gmail.com' \
--to=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sean.j.christopherson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.