[PATCH v2] [next] KVM: lapic: allow set apic debug dynamically

[PATCH v2] [next] KVM: lapic: allow set apic debug dynamically

[Yi Wang]

There are many functions invoke apic_debug(), which is defined
a null function by default, and that's incovenient for debuging
lapic.

This patch allows setting apic debug according to add a apic_dbg
parameter of kvm.

Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
---
v2: change apic_dbg to bool and tag __read_mostly. Thanks to Sean.

 arch/x86/kvm/lapic.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 9bf70cf..0827e7c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -54,8 +54,13 @@
 #define PRIu64 "u"
 #define PRIo64 "o"
 
+static bool apic_dbg __read_mostly;
+module_param(apic_dbg, bool, 0644);
+
 /* #define apic_debug(fmt,arg...) printk(KERN_WARNING fmt,##arg) */
-#define apic_debug(fmt, arg...) do {} while (0)
+#define apic_debug(fmt, arg...) do {  if (apic_dbg)   \
+	printk(KERN_DEBUG fmt, ##arg);    \
+} while (0)
 
 /* 14 is the version for Xeon and Pentium 8.4.8*/
 #define APIC_VERSION			(0x14UL | ((KVM_APIC_LVT_NUM - 1) << 16))
-- 
1.8.3.1

Re: [PATCH v2] [next] KVM: lapic: allow set apic debug dynamically

[Sean Christopherson]

On Thu, May 09, 2019 at 06:47:57PM +0800, Yi Wang wrote:
> There are many functions invoke apic_debug(), which is defined
> a null function by default, and that's incovenient for debuging
> lapic.
> 
> This patch allows setting apic debug according to add a apic_dbg
> parameter of kvm.
> 
> Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
> ---
> v2: change apic_dbg to bool and tag __read_mostly. Thanks to Sean.
> 
>  arch/x86/kvm/lapic.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 9bf70cf..0827e7c 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -54,8 +54,13 @@
>  #define PRIu64 "u"
>  #define PRIo64 "o"
>  
> +static bool apic_dbg __read_mostly;
> +module_param(apic_dbg, bool, 0644);

Probably don't need to shorten "debug".

> +
>  /* #define apic_debug(fmt,arg...) printk(KERN_WARNING fmt,##arg) */
> -#define apic_debug(fmt, arg...) do {} while (0)
> +#define apic_debug(fmt, arg...) do {  if (apic_dbg)   \
> +	printk(KERN_DEBUG fmt, ##arg);    \
> +} while (0)

Pulling in your comment regarding sched_debug and noirqdebug...

On Thu, May 09, 2019 at 08:29:38AM +0800, wang.yi59@zte.com.cn wrote:
> Also, we have some similar parameters already, such like sched_debug,
> noirqdebug :)

The IRQ debug hook is a completely different beast than the APIC debug
messages.

sched_debug is a much better comparison.  The param only exists if
CONFIG_SCHED_DEBUG=y, which is "default y" but "depends on DEBUG_KERNEL".
That seems like the route to go if we want the ability to toggle APIC
debugging at runtime.  And if we go with an all encompassing config,
e.g. CONFIG_KVM_DEBUG, we can use it to wrap x86/mmu.c's debug param as
well (and rename it to mmu_debug).

>  
>  /* 14 is the version for Xeon and Pentium 8.4.8*/
>  #define APIC_VERSION			(0x14UL | ((KVM_APIC_LVT_NUM - 1) << 16))
> -- 
> 1.8.3.1
> 

Re: [PATCH v2] [next] KVM: lapic: allow set apic debug dynamically

[Sean Christopherson]

On Fri, May 10, 2019 at 12:54:21PM +0800, wang.yi59@zte.com.cn wrote:
> I grep "debug" in arch/x86/kvm, and find these *_debug:
> ioapic_debug
> apic_debug
> 
> and dbg in mmu.c, which is better to be renamed to mmu_debug as you said.
> 
> and vcpu_debug, which uses kvm_debug macro.
> 
> kvm_debug macro uses pr_debug which can be dynamically set during running
> time, so, how about change all *_debug in kvm to pr_debug like vcpu_debug?

It's still the same end result, we're bloating and slowing KVM with code
and conditionals that aren't useful in normal operation.  grep vcpu_debug
a bit further and you'll see that the only uses in x86 are when the guest
has crashed, is being reset, or is accessing an unhandled MSR and KVM is
injecting a #GP in response.  In other words, the existing uses are only
in code that isn't remotely performance critical.

  hyperv.c: vcpu_debug(vcpu, "hv crash (0x%llx 0x%llx 0x%llx 0x%llx 0x%llx)\n",
  hyperv.c: vcpu_debug(vcpu, "hyper-v reset requested\n");
  x86.c:    vcpu_debug_ratelimited(vcpu, "unhandled wrmsr: 0x%x data 0x%llx\n",
  x86.c:    vcpu_debug_ratelimited(vcpu, "unhandled rdmsr: 0x%x\n",

pr_debug does have more direct uses, notably in nested VMX and KVM TSC
handling.  Similar to the above vcpu_debug case, the nVMX uses are all
failing paths and not performance critical.  The TSC code does have one
path that may affect performance (get_kvmclock_ns()->kvm_get_time_scale()),
but I don't think that should be considered as setting the precedent.  In
fact, it may make sense to convert the TSC pr_debugs to be gated by
CONFIG_DEBUG_KVM as well.

Paolo, do you have any thoughts?