From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: kvm@vger.kernel.org, Paul Durrant <paul@xen.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Michal Luczaj <mhal@rbox.co>,
David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [PATCH v2 1/8] KVM: x86/xen: improve accuracy of Xen timers
Date: Mon, 4 Mar 2024 15:44:39 -0800 [thread overview]
Message-ID: <ZeZc549aow68CeD-@google.com> (raw)
In-Reply-To: <20240227115648.3104-2-dwmw2@infradead.org>
On Tue, Feb 27, 2024, David Woodhouse wrote:
> + /* Xen has a 'Linux workaround' in do_set_timer_op() which
> + * checks for negative absolute timeout values (caused by
> + * integer overflow), and for values about 13 days in the
> + * future (2^50ns) which would be caused by jiffies
> + * overflow. For those cases, it sets the timeout 100ms in
> + * the future (not *too* soon, since if a guest really did
> + * set a long timeout on purpose we don't want to keep
> + * churning CPU time by waking it up).
> + */
I'm going to massage this slightly, partly to take advantage of reduced indentation,
but also to call out when the workaround is applied. Though in all honesty, the
extra context may just be in response to a PEBKAC on my end, as I misread the diff
multiple times.
> + if (linux_wa) {
> + if ((unlikely((int64_t)guest_abs < 0 ||
No need for a second set of parantheses around the unlikely.
> + (delta > 0 && (uint32_t) (delta >> 50) != 0)))) {
And this can all easily fit into one if-statement.
> + delta = 100 * NSEC_PER_MSEC;
> + guest_abs = guest_now + delta;
> + }
> + }
This is what I'm going to commit, holler if it looks wrong (disclaimer: I've only
compile tested at this point).
/*
* Xen has a 'Linux workaround' in do_set_timer_op() which checks for
* negative absolute timeout values (caused by integer overflow), and
* for values about 13 days in the future (2^50ns) which would be
* caused by jiffies overflow. For those cases, Xen sets the timeout
* 100ms in the future (not *too* soon, since if a guest really did
* set a long timeout on purpose we don't want to keep churning CPU
* time by waking it up). Emulate Xen's workaround when starting the
* timer in response to __HYPERVISOR_set_timer_op.
*/
if (linux_wa &&
unlikely((int64_t)guest_abs < 0 ||
(delta > 0 && (uint32_t) (delta >> 50) != 0))) {
delta = 100 * NSEC_PER_MSEC;
guest_abs = guest_now + delta;
}
next prev parent reply other threads:[~2024-03-04 23:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 11:49 [PATCH v2 0/8] KVM: x86/xen updates David Woodhouse
2024-02-27 11:49 ` [PATCH v2 1/8] KVM: x86/xen: improve accuracy of Xen timers David Woodhouse
2024-03-04 23:44 ` Sean Christopherson [this message]
2024-03-05 9:29 ` Paul Durrant
2024-03-05 21:12 ` Sean Christopherson
2024-03-06 9:48 ` Paul Durrant
2024-03-06 9:57 ` David Woodhouse
2024-02-27 11:49 ` [PATCH v2 2/8] KVM: x86/xen: inject vCPU upcall vector when local APIC is enabled David Woodhouse
2024-02-27 11:49 ` [PATCH v2 3/8] KVM: x86/xen: remove WARN_ON_ONCE() with false positives in evtchn delivery David Woodhouse
2024-02-27 11:49 ` [PATCH v2 4/8] KVM: pfncache: simplify locking and make more self-contained David Woodhouse
2024-03-05 0:08 ` Sean Christopherson
2024-02-27 11:49 ` [PATCH v2 5/8] KVM: x86/xen: fix recursive deadlock in timer injection David Woodhouse
2024-02-27 11:49 ` [PATCH v2 6/8] KVM: x86/xen: split up kvm_xen_set_evtchn_fast() David Woodhouse
2024-02-27 11:49 ` [PATCH v2 7/8] KVM: x86/xen: avoid blocking in hardirq context in kvm_xen_set_evtchn_fast() David Woodhouse
2024-02-27 14:43 ` Steven Rostedt
2024-02-27 17:00 ` David Woodhouse
2024-02-27 17:18 ` Thomas Gleixner
2024-02-27 17:22 ` David Woodhouse
2024-03-07 9:27 ` David Woodhouse
2024-03-07 10:02 ` David Woodhouse
2024-02-27 17:25 ` Steven Rostedt
2024-02-27 17:28 ` David Woodhouse
2024-03-08 18:10 ` David Woodhouse
2024-02-27 11:49 ` [PATCH v2 8/8] KVM: pfncache: clean up rwlock abuse David Woodhouse
2024-02-29 23:12 ` [PATCH v2 0/8] KVM: x86/xen updates Sean Christopherson
2024-03-05 0:35 ` Sean Christopherson
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=ZeZc549aow68CeD-@google.com \
--to=seanjc@google.com \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.co.uk \
--cc=kvm@vger.kernel.org \
--cc=mhal@rbox.co \
--cc=paul@xen.org \
--cc=pbonzini@redhat.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.