From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753352AbdGNDVW (ORCPT ); Thu, 13 Jul 2017 23:21:22 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:21120 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752849AbdGNDVU (ORCPT ); Thu, 13 Jul 2017 23:21:20 -0400 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="21274647" Subject: Re: [PATCH v8 1/5] x86: add simple udelay calibration To: Lu Baolu , Boris Ostrovsky , Greg Kroah-Hartman , Ingo Molnar , Mathias Nyman , References: <1490083293-3792-1-git-send-email-baolu.lu@linux.intel.com> <1490083293-3792-2-git-send-email-baolu.lu@linux.intel.com> <590C1084.7010302@linux.intel.com> <5966CA3F.2030402@linux.intel.com> <4b423b45-3b83-ead5-1205-a004d13dac77@cn.fujitsu.com> <5966E247.9090700@linux.intel.com> CC: , , , , Juergen Gross , xen-devel From: Dou Liyang Message-ID: Date: Fri, 14 Jul 2017 11:21:14 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5966E247.9090700@linux.intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 9AC5546B4C95.AB12D X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Lu At 07/13/2017 11:00 AM, Lu Baolu wrote: > Hi, > > On 07/13/2017 09:39 AM, Dou Liyang wrote: >> Hi, Lu >> >> At 07/13/2017 09:17 AM, Lu Baolu wrote: >>> Hi, >>> >>> On 07/12/2017 04:02 PM, Dou Liyang wrote: >>>> Hi, Lu >>>> >>>> At 05/05/2017 08:50 PM, Boris Ostrovsky wrote: >>>>> On 05/05/2017 01:41 AM, Lu Baolu wrote: >>>>>> Hi, >>>>>> >>>>>> On 05/03/2017 06:38 AM, Boris Ostrovsky wrote: >>>>>>> On 03/21/2017 04:01 AM, Lu Baolu wrote: >>>>>>>> Add a simple udelay calibration in x86 architecture-specific >>>>>>>> boot-time initializations. This will get a workable estimate >>>>>>>> for loops_per_jiffy. Hence, udelay() could be used after this >>>>>>>> initialization. >>>>>>> This breaks Xen PV guests since at this point, and until >>>>>>> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is >>>>>>> mapped, they cannot access pvclock. >>>>>>> >>>>>>> Is it reasonable to do this before tsc_init() is called? (The failure >>>>>>> has nothing to do with tsc_init(), really --- it's just that it is >>>>>>> called late enough that Xen PV guests get properly initialized.) If it >>>>>>> is, would it be possible to move simple_udelay_calibration() after >>>>>>> x86_init.paging.pagetable_init()? >>>>>> This is currently only used for bare metal. How about by-pass it >>>>>> for Xen PV guests? >>>>> >>>>> It is fixed this for Xen PV guests now (in the sense that we don't crash >>>>> anymore) but my question is still whether this is not too early. Besides >>>>> tsc_init() (which might not be important here), at the time when >>>>> simple_udelay_calibration() is invoked we haven't yet called: >>>>> * kvmclock_init(), which sets calibration routines for KVM >>>>> * init_hypervisor_platform(), which sets calibration routines for vmware >>>>> and Xen HVM >>>>> * x86_init.paging.pagetable_init(), which sets calibration routines for >>>>> Xen PV >>>>> >>>> >>>> I guess these may have been missed. >>>> >>>> Do you have any comments about these? >>>> >>> >>> The patch will be available in 4.13-rc1. >> >> Yes, I have seen it in the upstream. >> >> Firstly, I also met this problem want to call udelay() earlier than >> *loops_per_jiffy* setup like you[1]. So I am very interesting in this >> patch. ;) >> >> I am also confused about the questions which Boris asked: >> >> whether do the CPU and TSC calibration too early just for using >> udelay()? >> >> this design broke our interface of x86_paltform.calibrate_cpu/tsc. >> >> And I also have a question below. >> >> [...] >> >>>>>>>> >>>>>>>> +static void __init simple_udelay_calibration(void) >>>>>>>> +{ >>>>>>>> + unsigned int tsc_khz, cpu_khz; >>>>>>>> + unsigned long lpj; >>>>>>>> + >>>>>>>> + if (!boot_cpu_has(X86_FEATURE_TSC)) >>>>>>>> + return; >> >> if we don't have the TSC feature in booting CPU and >> it returns here, can we use udelay() correctly like before? >> > > If we have TSC feature, we calculate a preciser loops_per_jiffy here. > Otherwise, we just keep it as before. This function doesn't broke the > use of udelay(). Oh, I see. In XDbC (XHCI debug capability), we just want the udelay() work more precisely in the TSC supported system. It is different with my problem I missed. Thanks for your kind explanation. :) Thanks, dou > > Best regards, > Lu Baolu > >> >> [1] https://lkml.org/lkml/2017/7/3/276 >> >> Thanks, >> >> dou. >> >>>> Thanks, >>>> >>>> dou. >>>> >>>>>>>> + >>>>>>>> + cpu_khz = x86_platform.calibrate_cpu(); >>>>>>>> + tsc_khz = x86_platform.calibrate_tsc(); >>>>>>>> + >>>>>>>> + tsc_khz = tsc_khz ? : cpu_khz; >>>>>>>> + if (!tsc_khz) >>>>>>>> + return; >>>>>>>> + >>>>>>>> + lpj = tsc_khz * 1000; >>>>>>>> + do_div(lpj, HZ); >>>>>>>> + loops_per_jiffy = lpj; >>>>>>>> +} >>>>>>>> + >>>>>>>> /* >>>>>>>> * Determine if we were loaded by an EFI loader. If so, then we have also been >>>>>>>> * passed the efi memmap, systab, etc., so we should use these data structures >>>>>>>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p) >>>>>>>> */ >>>>>>>> x86_configure_nx(); >>>>>>>> >>>>>>>> + simple_udelay_calibration(); >>>>>>>> + >>>>>>>> parse_early_param(); >>>>>>>> >>>>>>>> #ifdef CONFIG_MEMORY_HOTPLUG >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> >>> >>> >>> >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > >