public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: RFC: convert KVMTRACE to event traces
Date: Fri, 15 May 2009 13:10:34 -0400	[thread overview]
Message-ID: <20090515171034.GA5324@infradead.org> (raw)
In-Reply-To: <20090514203016.GA10183@amt.cnet>

On Thu, May 14, 2009 at 05:30:16PM -0300, Marcelo Tosatti wrote:
> +		trace_kvm_cr_write(cr, val);
>  		switch (cr) {
>  		case 0:
> -			kvm_set_cr0(vcpu, kvm_register_read(vcpu, reg));
> +			kvm_set_cr0(vcpu, val);
>  			skip_emulated_instruction(vcpu);

Do we really need one trace point covering all cr writes, _and_ one for
each specific register?

>  	if (!npt_enabled)
> -		KVMTRACE_3D(PAGE_FAULT, &svm->vcpu, error_code,
> -			    (u32)fault_address, (u32)(fault_address >> 32),
> -			    handler);
> +		trace_kvm_page_fault(fault_address, error_code);
>  	else
> -		KVMTRACE_3D(TDP_FAULT, &svm->vcpu, error_code,
> -			    (u32)fault_address, (u32)(fault_address >> 32),
> -			    handler);
> +		trace_kvm_tdp_page_fault(fault_address, error_code);

Again this seems a bit cumbersome.  Why not just one tracepoint for
page faults, with a flag if we're using npt or not?

> +ifeq ($(CONFIG_TRACEPOINTS),y)
> +trace-objs = kvm-traces.o
> +arch-trace-objs = kvm-traces-arch.o
> +endif
> +
>  EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
>  
>  kvm-objs := $(common-objs) x86.o mmu.o x86_emulate.o i8259.o irq.o lapic.o \
> -	i8254.o
> +	i8254.o $(trace-objs)
>  obj-$(CONFIG_KVM) += kvm.o
> -kvm-intel-objs = vmx.o
> +kvm-intel-objs = vmx.o $(arch-trace-objs)
>  obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
> -kvm-amd-objs = svm.o
> +kvm-amd-objs = svm.o $(arch-trace-objs)
>  obj-$(CONFIG_KVM_AMD) += kvm-amd.o

The option to select even tracing bits is CONFIG_EVENT_TRACING and the
makefile syntax used here (both the original makefile and the additions)
is rather awkward.

A proper arch/x86/kvm/Makefile including tracing bits should look like
the following:

-- snip --
EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm

kvm-y			+= $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \
			   coalesced_mmio.o irq_comm.o)
kvm-$(CONFIG_KVM_TRACE)	+= $(addprefix ../../../virt/kvm/, kvm_trace.o)
kvm-$(CONFIG_IOMMU_API)	+= $(addprefix ../../../virt/kvm/, iommu.o)
kmv-y			+= x86.o mmu.o x86_emulate.o i8259.o irq.o lapic.o \
			   i8254.o

kvm-$(CONFIG_EVENT_TRACING) += kvm-traces.o
kvm-arch-trace-$(CONFIG_EVENT_TRACING) += kvm-traces-arch.o

kvm-intel-y		+= vmx.o $(kvm-arch-trace-y)
kvm-amd-y		+= svm.o $(kvm-arch-trace-y)

obj-$(CONFIG_KVM)	+= kvm.o
obj-$(CONFIG_KVM_INTEL)	+= kvm-intel.o
obj-$(CONFIG_KVM_AMD)	+= kvm-amd.o
-- snip --

and do we actually still need kvm_trace.o after this?

Anyway, I'll send the upstream part of the makefile cleanup out ASAP,
then you can rebase later.

> Index: linux-2.6-x86-2/arch/x86/kvm/kvm-traces.c
> ===================================================================
> --- /dev/null
> +++ linux-2.6-x86-2/arch/x86/kvm/kvm-traces.c
> @@ -0,0 +1,5 @@
> +#include <linux/sched.h>
> +
> +
> +#define CREATE_TRACE_POINTS
> +#include <trace/events/kvm/x86.h>

Can't we just put this into some other common .c file?  That would also
reduce the amount of makefile magic required.

> Index: linux-2.6-x86-2/arch/x86/kvm/kvm-traces-arch.c
> ===================================================================
> --- /dev/null
> +++ linux-2.6-x86-2/arch/x86/kvm/kvm-traces-arch.c
> @@ -0,0 +1,5 @@
> +#include <linux/sched.h>
> +
> +
> +#define CREATE_TRACE_POINTS
> +#include <trace/events/kvm/x86-arch.h>

Same for this one, especially as the makefile hackery required for this
one is even worse..


  reply	other threads:[~2009-05-15 17:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14 20:30 RFC: convert KVMTRACE to event traces Marcelo Tosatti
2009-05-15 17:10 ` Christoph Hellwig [this message]
2009-05-15 18:08   ` Marcelo Tosatti
2009-05-17 20:21     ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090515171034.GA5324@infradead.org \
    --to=hch@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox