From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, x86@kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Andy Lutomirski <luto@kernel.org>,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org
Subject: Re: [PATCH RFC 5/6] x86/kvm: pass stable clocksource to guests when running nested on Hyper-V
Date: Fri, 1 Dec 2017 18:45:30 +0100 [thread overview]
Message-ID: <20171201174529.GA17073@flask> (raw)
In-Reply-To: <20171201131321.918-6-vkuznets@redhat.com>
2017-12-01 14:13+0100, Vitaly Kuznetsov:
> Currently, KVM is able to work in 'masterclock' mode passing
> PVCLOCK_TSC_STABLE_BIT to guests when the clocksource we use on the host
> is TSC. When running nested on Hyper-V we normally use a different one:
> TSC page which is resistant to TSC frequency changes on event like L1
> migration. Add support for it in KVM.
>
> The only non-trivial change in the patch is in vgettsc(): when updating
> our gtod copy we now need to get both the clockread and tsc value.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> @@ -1374,6 +1375,11 @@ static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64 kernel_ns)
> +static inline int gtod_cs_mode_good(int mode)
"good" isn't saying much; I'd like to express that TSC is the underlying
clock ...
What about "bool gtod_is_based_on_tsc()"?
> +{
> + return mode == VCLOCK_TSC || mode == VCLOCK_HVCLOCK;
> +}
> +
> @@ -1606,9 +1625,17 @@ static inline u64 vgettsc(u64 *cycle_now)
> long v;
> struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
>
> - *cycle_now = read_tsc();
> + if (gtod->clock.vclock_mode == VCLOCK_HVCLOCK) {
> + u64 tsc_pg_val;
> +
> + tsc_pg_val = hv_read_tsc_page_tsc(hv_get_tsc_page(), cycle_now);
This function might fail to update cycle_now and return -1.
I guess we should propagate the failure in that case.
> + v = (tsc_pg_val - gtod->clock.cycle_last) & gtod->clock.mask;
> + } else {
> + /* VCLOCK_TSC */
> + *cycle_now = read_tsc();
> + v = (*cycle_now - gtod->clock.cycle_last) & gtod->clock.mask;
cycle_now is getting pretty confusing -- it still is TSC timestamp, but
now we also have the current cycle of gtod, which might be the TSC page
timestamp. Please rename cycle_now to tsc_timestamp in the call tree,
thanks.
next prev parent reply other threads:[~2017-12-01 17:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 13:13 [PATCH RFC 0/6] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V Vitaly Kuznetsov
2017-12-01 13:13 ` Vitaly Kuznetsov
2017-12-01 13:13 ` [PATCH RFC 1/6] x86/hyper-v: check for required priviliges in hyperv_init() Vitaly Kuznetsov
2017-12-01 13:13 ` [PATCH RFC 2/6] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously Vitaly Kuznetsov
2017-12-01 13:13 ` Vitaly Kuznetsov
2017-12-01 17:29 ` Stephen Hemminger
2017-12-01 17:29 ` Stephen Hemminger
2017-12-01 17:52 ` Paolo Bonzini
2017-12-04 9:08 ` Vitaly Kuznetsov
2017-12-04 9:08 ` Vitaly Kuznetsov
2017-12-01 13:13 ` [PATCH RFC 3/6] x86/hyper-v: reenlightenment notifications support Vitaly Kuznetsov
2017-12-01 13:13 ` Vitaly Kuznetsov
2017-12-01 13:13 ` [PATCH RFC 4/6] x86/hyper-v: redirect reenlightment notifications on CPU offlining Vitaly Kuznetsov
2017-12-01 13:13 ` Vitaly Kuznetsov
2017-12-01 13:13 ` [PATCH RFC 5/6] x86/kvm: pass stable clocksource to guests when running nested on Hyper-V Vitaly Kuznetsov
2017-12-01 13:13 ` Vitaly Kuznetsov
2017-12-01 17:45 ` Radim Krčmář [this message]
2017-12-01 13:13 ` [PATCH RFC 6/6] x86/kvm: support Hyper-V reenlightenment Vitaly Kuznetsov
2017-12-01 13:13 ` Vitaly Kuznetsov
2017-12-01 16:11 ` [PATCH RFC 0/6] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V Paolo Bonzini
2017-12-01 16:11 ` Paolo Bonzini
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=20171201174529.GA17073@flask \
--to=rkrcmar@redhat.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=sthemmin@microsoft.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
/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.