From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH RFC 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va Date: Mon, 28 Dec 2015 15:45:22 -0800 Message-ID: References: <1451339557-24473-1-git-send-email-joao.m.martins@oracle.com> <1451339557-24473-2-git-send-email-joao.m.martins@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1451339557-24473-2-git-send-email-joao.m.martins@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Joao Martins Cc: Marcelo Tosatti , kvm list , Gleb Natapov , X86 ML , "linux-kernel@vger.kernel.org" , xen-devel , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Paolo Bonzini , Thomas Gleixner , Borislav Petkov List-Id: xen-devel@lists.xenproject.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