From mboxrd@z Thu Jan  1 00:00:00 1970
From: Joao Martins <joao.m.martins@oracle.com>
Subject: Re: [PATCH v1 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va
Date: Thu, 26 Jan 2017 19:58:09 +0000
Message-ID: <588A54D1.2000606@oracle.com>
References: <1485365586-21653-1-git-send-email-joao.m.martins@oracle.com>
 <1485365586-21653-2-git-send-email-joao.m.martins@oracle.com>
 <CALCETrVrudyoaJAOtACnkpuZ0TEpvcEAaapkWuutC613JDbJrA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        kvm list <kvm@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Radim Krcmar <rkrcmar@redhat.com>,
        xen-devel <xen-devel@lists.xenproject.org>
To: Andy Lutomirski <luto@amacapital.net>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <CALCETrVrudyoaJAOtACnkpuZ0TEpvcEAaapkWuutC613JDbJrA@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On 01/26/2017 05:25 PM, Andy Lutomirski wrote:
> On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins <joao.m.martins@oracle.com> wrote:
>> Right now there is only a pvclock_pvti_cpu0_va() which is defined
>> on kvmclock since:
>>
>> commit dac16fba6fc5
>> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
>>
>> The only user of this interface was kvm. This commit moves
>> pvclock_pvti_cpu0_va to pvclock which is a more generic place to have it
>> and adds the correspondent setter routine for it. This allows other
>> pvclock-based clocksources to use it, such as Xen.
> 
> With a minor nit:
> 
> Acked-by: Andy Lutomirski <luto@kernel.org>
> 
>> +#else
>> +static inline void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
>> +{
>> +}
> 
> How about just not providing pvclock_set_pvti_cpu0_va() in this case?
> It'll save three lines of code, and, more importantly, it will force
> us to notice if we screw up the Kconfig stuff.
Sounds good, will remove this then. Thanks!

Joao