From: Marcelo Tosatti <mtosatti@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: kvm@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: RFC: convert KVMTRACE to event traces
Date: Fri, 15 May 2009 15:08:19 -0300 [thread overview]
Message-ID: <20090515180819.GA11166@amt.cnet> (raw)
In-Reply-To: <20090515171034.GA5324@infradead.org>
On Fri, May 15, 2009 at 01:10:34PM -0400, Christoph Hellwig wrote:
> 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?
There is one tracepoint named kvm_cr that covers cr reads and writes.
kvm_trace_cr_read/kvm_trace_cr_write are macros that expand to
kvm_trace_cr(rw=1 or rw=0). Perhaps that is not a very good idea.
>
> > 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?
Issue is the meaning of these faults is different. With npt disabled the
fault is a guest fault (like a normal pagefault), but with npt enabled
the fault indicates the host pagetables the hardware uses to do the
translation are not set up correctly.
I did unify them as you suggest but reverted back to separate
tracepoints because the unification might be confusing.
Can be unified later if desirable.
> > +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?
Your version looks much nicer. kvm_trace.o can disappear as soon as
this is in Avi's tree and a decent replacement for user/kvm_trace.c
is in qemu-kvm.git.
> Anyway, I'll send the upstream part of the makefile cleanup out ASAP,
> then you can rebase later.
OK.
>
> > 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..
Probably for both. Now that you say I can't explain the reason for the
separate C files. Will put this up in a git tree in a couple of hours.
next prev parent reply other threads:[~2009-05-15 18:08 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
2009-05-15 18:08 ` Marcelo Tosatti [this message]
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=20090515180819.GA11166@amt.cnet \
--to=mtosatti@redhat.com \
--cc=hch@infradead.org \
--cc=kvm@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.