usb: early: add support for early printk through USB3 debug port

Commit-ID:  dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
Gitweb:     http://git.kernel.org/tip/dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
Author:     Lu Baolu <[email protected]>
AuthorDate: Tue, 21 Mar 2017 16:01:29 +0800
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 21 Mar 2017 12:28:45 +0100

x86/timers: Add simple udelay calibration

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.

Signed-off-by Lu Baolu <[email protected]>

Acked-by Thomas Gleixner <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Brian Gerst <[email protected]>

Cc Denys Vlasenko <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc H. Peter Anvin <[email protected]>

Cc Josh Poimboeuf <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Mathias Nyman <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc [email protected]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +20 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;
+
+	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

Quoted 68 lines · tip-bot for Lu Baolu

Commit-ID:  dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
Gitweb:     http://git.kernel.org/tip/dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
Author:     Lu Baolu <[email protected]>
AuthorDate: Tue, 21 Mar 2017 16:01:29 +0800
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 21 Mar 2017 12:28:45 +0100

x86/timers: Add simple udelay calibration

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.

Signed-off-by Lu Baolu <[email protected]>

Acked-by Thomas Gleixner <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Brian Gerst <[email protected]>

Cc Denys Vlasenko <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc H. Peter Anvin <[email protected]>

Cc Josh Poimboeuf <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Mathias Nyman <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc [email protected]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +20 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;
+
+	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();
 

arch/x86/kernel/setup.c void __init setup_arch(char **cmdline_p) · line 1012

Quoted 6 lines

arch/x86/kernel/setup.c +2 -0

+	simple_udelay_calibration();
+
 	parse_early_param();
 
 #ifdef CONFIG_MEMORY_HOTPLUG

Can we move this past init_hypervisor_platform()?

Otherwise, the
x86_platform hooks aren't fully initialized yet, and we may use the wrong functions.

Jan

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.

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +20 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;
+
+	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

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.

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +22 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;
+
+	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

Quoted 4 lines · Lu Baolu

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()?

-boris

Quoted 42 lines

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +20 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;
+
+	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();
 

arch/x86/kernel/setup.c void __init setup_arch(char **cmdline_p) · line 1012

Quoted 5 lines

arch/x86/kernel/setup.c +2 -0

+	simple_udelay_calibration();
+
 	parse_early_param();
 
 #ifdef CONFIG_MEMORY_HOTPLUG

Quoted 4 lines · Lu Baolu

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()?

-boris

Quoted 47 lines

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +22 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;
+
+	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

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 5 lines

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?

Best regards,
Lu Baolu

Quoted 45 lines

-boris

Quoted 42 lines

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +20 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;
+
+	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();
 

Quoted 5 lines

arch/x86/kernel/setup.c void __init setup_arch(char **cmdline_p) · line 1012

Quoted 5 lines

arch/x86/kernel/setup.c +2 -0

+	simple_udelay_calibration();
+
 	parse_early_param();
 
 #ifdef CONFIG_MEMORY_HOTPLUG

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 5 lines

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?

Best regards,
Lu Baolu

Quoted 50 lines

-boris

Quoted 47 lines

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +22 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;
+
+	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

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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

-boris

Quoted 22 lines

Best regards,
Lu Baolu

Quoted 18 lines

-boris

Quoted 15 lines

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +0 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 

Quoted 7 lines

Quoted 7 lines

arch/x86/kernel/setup.c dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) · line 846

Quoted 7 lines

arch/x86/kernel/setup.c +7 -0

+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;

Quoted 20 lines

Quoted 20 lines

Quoted 20 lines

arch/x86/kernel/setup.c +13 -0

+
+	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();
 

Quoted 5 lines

Quoted 5 lines

arch/x86/kernel/setup.c void __init setup_arch(char **cmdline_p) · line 1012

Quoted 5 lines

arch/x86/kernel/setup.c +2 -0

+	simple_udelay_calibration();
+
 	parse_early_param();
 
 #ifdef CONFIG_MEMORY_HOTPLUG

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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

-boris

Quoted 22 lines

Best regards,
Lu Baolu

Quoted 18 lines

-boris

Quoted 15 lines

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +0 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 

Quoted 7 lines

Quoted 7 lines

arch/x86/kernel/setup.c dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) · line 846

Quoted 7 lines

arch/x86/kernel/setup.c +7 -0

+static void __init simple_udelay_calibration(void)
+{
+	unsigned int tsc_khz, cpu_khz;
+	unsigned long lpj;
+
+	if (!boot_cpu_has(X86_FEATURE_TSC))
+		return;

Quoted 25 lines

Quoted 25 lines

Quoted 25 lines

arch/x86/kernel/setup.c +15 -0

+
+	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

Hi, Lu

Quoted 21 lines · Boris Ostrovsky

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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?

Quoted 10 lines

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?

Quoted 25 lines

-boris

Quoted 22 lines

Best regards,
Lu Baolu

Quoted 18 lines

-boris

Quoted 15 lines

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +0 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
     return 0;
 }
 

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

arch/x86/kernel/setup.c dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) · line 846

Quoted 7 lines

arch/x86/kernel/setup.c +7 -0

+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 it returns here, can we use udelay() correctly like before?

Thanks,

dou.

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

arch/x86/kernel/setup.c +15 -0

+
+    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();
 

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

arch/x86/kernel/setup.c +0 -0

 #ifdef CONFIG_MEMORY_HOTPLUG

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi, Lu

Quoted 21 lines · Boris Ostrovsky

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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?

Quoted 10 lines

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?

Quoted 25 lines

-boris

Quoted 22 lines

Best regards,
Lu Baolu

Quoted 18 lines

-boris

Quoted 15 lines

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Signed-off-by Lu Baolu <[email protected]>

---
 arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

arch/x86/kernel/setup.c +0 -0

index 4bf0c89..e70204e 100644
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
     return 0;
 }
 

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

arch/x86/kernel/setup.c dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) · line 846

Quoted 7 lines

arch/x86/kernel/setup.c +7 -0

+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 it returns here, can we use udelay() correctly like before?

Thanks,

dou.

Quoted 29 lines

Quoted 25 lines

Quoted 25 lines

Quoted 25 lines

arch/x86/kernel/setup.c +15 -0

+
+    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

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 35 lines · Dou Liyang

Hi, Lu

Quoted 31 lines · Boris Ostrovsky

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 4 lines

I guess these may have been missed.

Do you have any comments about these?

The patch will be available in 4.13-rc1.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

arch/x86/kernel/setup.c dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) · line 846

Quoted 8 lines

arch/x86/kernel/setup.c +7 -0

+static void __init simple_udelay_calibration(void)
+{
+    unsigned int tsc_khz, cpu_khz;
+    unsigned long lpj;
+
+    if (!boot_cpu_has(X86_FEATURE_TSC))
+        return;

Quoted 35 lines

Thanks,

dou.

Quoted 29 lines

Quoted 25 lines

Quoted 25 lines

Quoted 25 lines

arch/x86/kernel/setup.c +15 -0

+
+    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

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 35 lines · Dou Liyang

Hi, Lu

Quoted 31 lines · Boris Ostrovsky

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 4 lines

I guess these may have been missed.

Do you have any comments about these?

The patch will be available in 4.13-rc1.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

arch/x86/kernel/setup.c dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) · line 846

Quoted 8 lines

arch/x86/kernel/setup.c +7 -0

+static void __init simple_udelay_calibration(void)
+{
+    unsigned int tsc_khz, cpu_khz;
+    unsigned long lpj;
+
+    if (!boot_cpu_has(X86_FEATURE_TSC))
+        return;

Quoted 40 lines

Thanks,

dou.

Quoted 20 lines

Quoted 20 lines

Quoted 20 lines

Quoted 20 lines

arch/x86/kernel/setup.c +13 -0

+
+    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();
 

Quoted 9 lines

Quoted 5 lines

Quoted 5 lines

arch/x86/kernel/setup.c void __init setup_arch(char **cmdline_p) · line 1012

Quoted 5 lines

arch/x86/kernel/setup.c +2 -0

+    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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi, Lu

Quoted 38 lines · Lu Baolu

Hi,

Quoted 35 lines · Dou Liyang

Hi, Lu

Quoted 31 lines · Boris Ostrovsky

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 6 lines

Quoted 4 lines

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.

[...]

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Review

Quoted 7 lines

(quoted diff) +7 -0

+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?

[1] https://lkml.org/lkml/2017/7/3/276

Thanks,

dou.

Quoted 35 lines

Quoted 35 lines

Thanks,

dou.

Quoted 29 lines

Quoted 25 lines

Quoted 25 lines

Quoted 25 lines

(quoted diff) +15 -0

+
+    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

Quoted 9 lines

Quoted 5 lines

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi, Lu

Quoted 38 lines · Lu Baolu

Hi,

Quoted 35 lines · Dou Liyang

Hi, Lu

Quoted 31 lines · Boris Ostrovsky

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 6 lines

Quoted 4 lines

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.

[...]

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Review

Quoted 7 lines

(quoted diff) +7 -0

+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?

[1] https://lkml.org/lkml/2017/7/3/276

Thanks,

dou.

Quoted 44 lines

Quoted 40 lines

Thanks,

dou.

Quoted 29 lines

Quoted 25 lines

Quoted 25 lines

Quoted 25 lines

(quoted diff) +15 -0

+
+    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

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 66 lines · Dou Liyang

Hi, Lu

Quoted 38 lines · Lu Baolu

Hi,

Quoted 35 lines · Dou Liyang

Hi, Lu

Quoted 31 lines · Boris Ostrovsky

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 6 lines

Quoted 4 lines

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.

[...]

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 11 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Review

Quoted 7 lines

(quoted diff) +7 -0

+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().

Best regards,
Lu Baolu

Quoted 58 lines

[1] https://lkml.org/lkml/2017/7/3/276

Thanks,

dou.

Quoted 35 lines

Quoted 35 lines

Thanks,

dou.

Quoted 29 lines

Quoted 25 lines

Quoted 25 lines

Quoted 25 lines

(quoted diff) +15 -0

+
+    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

Quoted 9 lines

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 66 lines · Dou Liyang

Hi, Lu

Quoted 38 lines · Lu Baolu

Hi,

Quoted 35 lines · Dou Liyang

Hi, Lu

Quoted 31 lines · Boris Ostrovsky

Quoted 12 lines · Lu Baolu

Hi,

Quoted 9 lines · Boris Ostrovsky

Quoted 4 lines · Lu Baolu

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 6 lines

Quoted 4 lines

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.

[...]

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 11 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Review

Quoted 7 lines

(quoted diff) +7 -0

+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().

Best regards,
Lu Baolu

Quoted 58 lines

[1] https://lkml.org/lkml/2017/7/3/276

Thanks,

dou.

Quoted 35 lines

Quoted 35 lines

Thanks,

dou.

Quoted 29 lines

Quoted 25 lines

Quoted 25 lines

Quoted 25 lines

(quoted diff) +15 -0

+
+    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

Quoted 9 lines

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in the section 7.6.

This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work.

One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd.

Cc Ingo Molnar <[email protected]>

Cc Mathias Nyman <[email protected]>

Signed-off-by Lu Baolu <[email protected]>

Quoted 26 lines · Lu Baolu

XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in the section 7.6.

This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work.

One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd.

Cc Ingo Molnar <[email protected]>

Cc Mathias Nyman <[email protected]>

Signed-off-by Lu Baolu <[email protected]>

...

drivers/usb/early/xhci-dbc.c line 37

Quoted 4 lines

drivers/usb/early/xhci-dbc.c new file +4 -0

+
+#define XDBC_TRACE
+#ifdef XDBC_TRACE
+#define	xdbc_trace	trace_printk

Did you forget to remove the #define XDBC_TRACE?

Enabling this driver brings the "trace_printk() being used. Allocating extra memory. This means that this is a DEBUG kernel and it is unsafe for production use." message in 4.12-rcX dmesg.

Thanks,
Vlastimil

Quoted 6 lines

drivers/usb/early/xhci-dbc.c line 37

Quoted 4 lines

drivers/usb/early/xhci-dbc.c new file +4 -0

+
+#define XDBC_TRACE
+#ifdef XDBC_TRACE
+#define	xdbc_trace	trace_printk  

Did you forget to remove the #define XDBC_TRACE?

Quoted 3 lines

Enabling this driver brings the "trace_printk() being used. Allocating extra memory. This means that this is a DEBUG kernel and it is unsafe for production use." message in 4.12-rcX dmesg.

This feature is only for a DEBUG kernel, should not be enabled for any production kernel. This was the reason I enabled trace_printk() by default.

Quoted 9 lines · On Wed, 31 May 2017 11:27:19 +0800 Lu Baolu <[email protected]> wrote:

Quoted 9 lines

drivers/usb/early/xhci-dbc.c line 37

Quoted 4 lines

drivers/usb/early/xhci-dbc.c new file +4 -0

+
+#define XDBC_TRACE
+#ifdef XDBC_TRACE
+#define	xdbc_trace	trace_printk  

Did you forget to remove the #define XDBC_TRACE?

Enabling this driver brings the "trace_printk() being used. Allocating extra memory. This means that this is a DEBUG kernel and it is unsafe for production use." message in 4.12-rcX dmesg.

Quoted 3 lines

This feature is only for a DEBUG kernel, should not be enabled for any production kernel. This was the reason I enabled trace_printk() by default.

Yes, it is perfectly fine to use trace_printk() for debug only configs. But if if you have it there and it is helpful to debug something that happens in a production system, you may want to look into creating a real tracepoint for the locations.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 35 lines · Vlastimil Babka

Quoted 26 lines · Lu Baolu

XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in the section 7.6.

This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work.

One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd.

Cc Ingo Molnar <[email protected]>

Cc Mathias Nyman <[email protected]>

Signed-off-by Lu Baolu <[email protected]>

...

drivers/usb/early/xhci-dbc.c line 37

Quoted 4 lines

drivers/usb/early/xhci-dbc.c new file +4 -0

+
+#define XDBC_TRACE
+#ifdef XDBC_TRACE
+#define	xdbc_trace	trace_printk

Did you forget to remove the #define XDBC_TRACE?

Quoted 3 lines

Enabling this driver brings the "trace_printk() being used. Allocating extra memory. This means that this is a DEBUG kernel and it is unsafe for production use." message in 4.12-rcX dmesg.

This feature is only for a DEBUG kernel, should not be enabled for any production kernel. This was the reason I enabled trace_printk() by default.

Best regards,
Lu Baolu

Quoted 3 lines

Thanks,
Vlastimil

Quoted 38 lines · Lu Baolu

Hi,

Quoted 35 lines · Vlastimil Babka

Quoted 26 lines · Lu Baolu

XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in the section 7.6.

This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work.

One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd.

Cc Ingo Molnar <[email protected]>

Cc Mathias Nyman <[email protected]>

Signed-off-by Lu Baolu <[email protected]>

...

drivers/usb/early/xhci-dbc.c line 37

Quoted 4 lines

drivers/usb/early/xhci-dbc.c new file +4 -0

+
+#define XDBC_TRACE
+#ifdef XDBC_TRACE
+#define	xdbc_trace	trace_printk

Did you forget to remove the #define XDBC_TRACE?

Quoted 6 lines

Quoted 3 lines

Enabling this driver brings the "trace_printk() being used. Allocating extra memory. This means that this is a DEBUG kernel and it is unsafe for production use." message in 4.12-rcX dmesg.

This feature is only for a DEBUG kernel, should not be enabled for any production kernel. This was the reason I enabled trace_printk() by default.

Hmm, but it seems we generally enable all these early printk features/drivers in our distro kernels. They are not active without a early_printk=X bootparam anyway, right? It's much more convenient to e.g. just tell customer to change a param when debugging something than to install a debug kernel. So I wouldn't agree that only a DEBUG kernel should have this compiled in.

Thanks,
Vlastimil

Quoted 6 lines

Best regards,
Lu Baolu

Quoted 3 lines

Thanks,
Vlastimil

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 13 lines · Vlastimil Babka

Quoted 12 lines · Lu Baolu

Hi,

Quoted 6 lines · Vlastimil Babka

On 03/21/2017 09:01 AM, Lu Baolu wrote:
Did you forget to remove the #define XDBC_TRACE?

Enabling this driver brings the "trace_printk() being used. Allocating extra memory. This means that this is a DEBUG kernel and it is unsafe for production use." message in 4.12-rcX dmesg.

This feature is only for a DEBUG kernel, should not be enabled for any production kernel. This was the reason I enabled trace_printk() by default.

Quoted 6 lines

Hmm, but it seems we generally enable all these early printk features/drivers in our distro kernels. They are not active without a early_printk=X bootparam anyway, right? It's much more convenient to e.g. just tell customer to change a param when debugging something than to install a debug kernel. So I wouldn't agree that only a DEBUG kernel should have this compiled in.

Okay, I will try to find a fix.

Thanks. I didn't make it clear that the trace_printk() warning is there even if the code using it doesn't actually execute (i.e. I didn't specify any early_printk bootparam). There are some roastedy tricks to detect the potential users, so that the buffers can be allocated in advance to allow the first trace_printk() from any context, I guess.

I'm not sure if there's a way to change it so that your driver reports the trace_printk usage only in response to the bootparam (which could also be a safe point to allocate ftrace buffers?).

Quoted 7 lines · Vlastimil Babka

Thanks. I didn't make it clear that the trace_printk() warning is there even if the code using it doesn't actually execute (i.e. I didn't specify any early_printk bootparam). There are some roastedy tricks to detect the potential users, so that the buffers can be allocated in advance to allow the first trace_printk() from any context, I guess.

Quoted 3 lines

I'm not sure if there's a way to change it so that your driver reports the trace_printk usage only in response to the bootparam (which could also be a safe point to allocate ftrace buffers?).

No, nor do we want to. There should not be a single caller to trace_printk() in normal kernels.

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of xHCI host.

This patch set adds support for early printk functionality through a USB3 debug port by 1) initializing and enabling the DbC hardware during early boot; 2) registering a boot console to the system so that early printk messages can go through the USB3 debug port. It also includes some lines of changes in usb_debug driver so that it can be bound when a USB3 debug device is enumerated.

Lu Baolu (5):
x86: add simple udelay calibration
usb: early: add driver for xhci debug capability
x86: add support for earlyprintk via USB3 debug port
usb: serial: add dbc debug device support to usb_debug
usb: doc: add document for USB3 debug port usage

 Documentation/admin-guide/kernel-parameters.txt |    1 +
 Documentation/usb/usb3-debug-port.rst           |  100 +++
 arch/x86/Kconfig.debug                          |   23 +
 arch/x86/kernel/early_printk.c                  |    5 +
 arch/x86/kernel/setup.c                         |   26 +
 drivers/usb/Makefile                            |    2 +-
 drivers/usb/early/Makefile                      |    1 +
 drivers/usb/early/xhci-dbc.c                    | 1014 +++++++++++++++++++++++
 drivers/usb/early/xhci-dbc.h                    |  211 +++++
 drivers/usb/serial/usb_debug.c                  |   28 +-
 include/linux/usb/xhci-dbgp.h                   |   29 +
 11 files changed, 1436 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/usb/usb3-debug-port.rst
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.h

Quoted 17 lines · Lu Baolu

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of xHCI host.

This patch set adds support for early printk functionality through a USB3 debug port by 1) initializing and enabling the DbC hardware during early boot; 2) registering a boot console to the system so that early printk messages can go through the USB3 debug port. It also includes some lines of changes in usb_debug driver so that it can be bound when a USB3 debug device is enumerated.

[...]

Quoted 8 lines

Lu Baolu (5):
x86: add simple udelay calibration
usb: early: add driver for xhci debug capability
x86: add support for earlyprintk via USB3 debug port
usb: serial: add dbc debug device support to usb_debug
usb: doc: add document for USB3 debug port usage

Quoted 16 lines

 Documentation/admin-guide/kernel-parameters.txt |    1 +
 Documentation/usb/usb3-debug-port.rst           |  100 +++
 arch/x86/Kconfig.debug                          |   23 +
 arch/x86/kernel/early_printk.c                  |    5 +
 arch/x86/kernel/setup.c                         |   26 +
 drivers/usb/Makefile                            |    2 +-
 drivers/usb/early/Makefile                      |    1 +
 drivers/usb/early/xhci-dbc.c                    | 1014 +++++++++++++++++++++++
 drivers/usb/early/xhci-dbc.h                    |  211 +++++
 drivers/usb/serial/usb_debug.c                  |   28 +-
 include/linux/usb/xhci-dbgp.h                   |   29 +
 11 files changed, 1436 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/usb/usb3-debug-port.rst
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.h

Ok, this has now become a high quality series with picture-perfect patches AFAICS.

Thomas also gave his Acked-by to all the patches.

I've applied them locally to -tip (it appears the USB maintainers are still fine with this being carried in tip:x86/debug for a v4.12 merge, right?), and will push them out and will propagate them to linux-next as well if they pass testing.

Quoted 4 lines

I've applied them locally to -tip (it appears the USB maintainers are still fine with this being carried in tip:x86/debug for a v4.12 merge, right?), and will push them out and will propagate them to linux-next as well if they pass testing.

Yes, no objection from me.

Quoted 23 lines

Lu Baolu (5):

Quoted 22 lines

x86: add simple udelay calibration
usb: early: add driver for xhci debug capability
x86: add support for earlyprintk via USB3 debug port
usb: serial: add dbc debug device support to usb_debug
usb: doc: add document for USB3 debug port usage

 Documentation/admin-guide/kernel-parameters.txt |    1 +
 Documentation/usb/usb3-debug-port.rst           |  100 +++
 arch/x86/Kconfig.debug                          |   23 +
 arch/x86/kernel/early_printk.c                  |    5 +
 arch/x86/kernel/setup.c                         |   26 +
 drivers/usb/Makefile                            |    2 +-
 drivers/usb/early/Makefile                      |    1 +
 drivers/usb/early/xhci-dbc.c                    | 1014 +++++++++++++++++++++++
 drivers/usb/early/xhci-dbc.h                    |  211 +++++
 drivers/usb/serial/usb_debug.c                  |   28 +-
 include/linux/usb/xhci-dbgp.h                   |   29 +
 11 files changed, 1436 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/usb/usb3-debug-port.rst
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.h

Ok, this has now become a high quality series with picture-perfect patches AFAICS.

Thomas also gave his Acked-by to all the patches.

I've applied them locally to -tip (it appears the USB maintainers are still fine with this being carried in tip:x86/debug for a v4.12 merge, right?), and will push them out and will propagate them to linux-next as well if they pass testing.

Thanks for the great work!