From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Stephen Hemminger" <sthemmin@microsoft.com>,
kvm@vger.kernel.org, "Radim Krčmář" <rkrcmar@redhat.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
"Ingo Molnar" <mingo@redhat.com>,
"Andy Lutomirski" <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
devel@linuxdriverproject.org,
"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: [PATCH RFC 2/6] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously
Date: Mon, 04 Dec 2017 10:08:52 +0100 [thread overview]
Message-ID: <87o9neoo63.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <77674d0f-f4c6-ad47-1984-ea040e256501@redhat.com> (Paolo Bonzini's message of "Fri, 1 Dec 2017 18:52:48 +0100")
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 01/12/2017 18:29, Stephen Hemminger wrote:
>>> +static inline u64 hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg,
>>> + u64 *cur_tsc)
>>> +{
>>> + *cur_tsc = rdtsc();
>>> +
>>> + return cur_tsc;
>> Why do return and setting by reference. Looks like an ugly API.
>
> This is the fallback implementation for !CONFIG_HYPERV_TSCPAGE, which
> explains why it's ugly, but why is it needed at all (or it could just
> BUG())?
>
It is not needed indeed, the intention was just to avoid '#if
IS_ENABLED(CONFIG_HYPERV)' in kvm code. I can replace it with BUG() or
return U64_MAX;
--
Vitaly
WARNING: multiple messages have this Message-ID (diff)
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Stephen Hemminger" <stephen@networkplumber.org>,
"Stephen Hemminger" <sthemmin@microsoft.com>,
kvm@vger.kernel.org, "Radim Krčmář" <rkrcmar@redhat.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
"Ingo Molnar" <mingo@redhat.com>,
"Andy Lutomirski" <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
devel@linuxdriverproject.org,
"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: [PATCH RFC 2/6] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously
Date: Mon, 04 Dec 2017 10:08:52 +0100 [thread overview]
Message-ID: <87o9neoo63.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <77674d0f-f4c6-ad47-1984-ea040e256501@redhat.com> (Paolo Bonzini's message of "Fri, 1 Dec 2017 18:52:48 +0100")
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 01/12/2017 18:29, Stephen Hemminger wrote:
>>> +static inline u64 hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg,
>>> + u64 *cur_tsc)
>>> +{
>>> + *cur_tsc = rdtsc();
>>> +
>>> + return cur_tsc;
>> Why do return and setting by reference. Looks like an ugly API.
>
> This is the fallback implementation for !CONFIG_HYPERV_TSCPAGE, which
> explains why it's ugly, but why is it needed at all (or it could just
> BUG())?
>
It is not needed indeed, the intention was just to avoid '#if
IS_ENABLED(CONFIG_HYPERV)' in kvm code. I can replace it with BUG() or
return U64_MAX;
--
Vitaly
next prev parent reply other threads:[~2017-12-04 9:08 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 [this message]
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ář
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=87o9neoo63.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sthemmin@microsoft.com \
--cc=tglx@linutronix.de \
--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.