From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752910AbbL1Xpp (ORCPT ); Mon, 28 Dec 2015 18:45:45 -0500 Received: from mail-ob0-f176.google.com ([209.85.214.176]:36601 "EHLO mail-ob0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752783AbbL1Xpm (ORCPT ); Mon, 28 Dec 2015 18:45:42 -0500 MIME-Version: 1.0 In-Reply-To: <1451339557-24473-2-git-send-email-joao.m.martins@oracle.com> References: <1451339557-24473-1-git-send-email-joao.m.martins@oracle.com> <1451339557-24473-2-git-send-email-joao.m.martins@oracle.com> From: Andy Lutomirski Date: Mon, 28 Dec 2015 15:45:22 -0800 Message-ID: Subject: Re: [PATCH RFC 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va To: Joao Martins Cc: "linux-kernel@vger.kernel.org" , kvm list , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Gleb Natapov , Paolo Bonzini , Andy Lutomirski , Borislav Petkov , Marcelo Tosatti , xen-devel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 28, 2015 at 1:52 PM, Joao Martins 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 so far is kvm. This commit adds a setter > function for the pvti page and moves pvclock_pvti_cpu0_va to pvclock, which > is a more generic place to have it; and would allow other PV clocksources > to use it, such as Xen. > > + > +void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti) > +{ > + pvti_cpu0_va = pvti; > +} IMO this either wants to be __init or wants a WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)). The latter hasn't landed in -tip yet, but I think it'll land next week unless the merge window opens early. It may pay to actually separate out the kvm-clock clocksource and rename it rather than partially duplicating it, assuming the result wouldn't be messy. Can you CC me on the rest of the series for new versions? BTW, since this seems to require hypervisor changes to be useful, it might make sense to rethink the interface a bit. Are you actually planning to support per-cpu pvti for this in any useful way? If not, I think that this would work a whole lot better and be considerably less code if you had a single global pvti that lived in hypervisor-allocated memory instead of an array that lives in guest memory. I'd be happy to discuss next week in more detail (currently on vacation). --Andy