There's no need to share writably the t_info pages (Dom0 only wants
[and needs] to read it)
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
This patch eliminate the global variables in libxenctrl (used for
logging and error reporting).
Instead the information which was in the global variables is now in a
new xc_interface* opaque structure, which xc_interface open returns
instead of the raw file descriptor; furthermore, logging is done via
xentoollog.
There are three new parameters to xc_interface_open to control the
logging, but existing callers can just pass "0" for all three to get
the old behaviour.
All libxc callers have been adjusted accordingly.
Also update QEMU_TAG for corresponding qemu change.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add an option that will set up the buffers and listen for updates,
but will not enable tracing. This is useful if you have hacks
in Xen to enable tracing at key points (for example, debugging a
shadow bug).
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Skip to the next "low" cpu when throwing away portions of the circular
memory buffer. This makes subsequent analysis easier.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
When interrupted, first disable tracing, then read through the records
one last time.
Without this patch, it's possible to get traces which interact (such
as runstate changes) on processors with higher numbers, while missing
the corresponding traces generated on lower-numbered processors.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
20827:fad80160c001 cannot be compiled on ia64:
xentrace.c:647: error: 'PAGE_SIZE' undeclared (first use in this
This patch fixes it.
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
In the current xentrace configuration, xentrace buffers are all
allocated in a single contiguous chunk, and then divided among logical
cpus, one buffer per cpu. The size of an allocatable chunk is fairly
limited, in my experience about 128 pages (512KiB). As the number of
logical cores increase, this means a much smaller maximum per-cpu
trace buffer per cpu; on my dual-socket quad-core nehalem box with
hyperthreading (16 logical cpus), that comes to 8 pages per logical
cpu.
This patch addresses this issue by allocating per-cpu buffers
separately.
Signed-off-by: George Dunlap <dunlapg@umich.edu>
xentrace_format cannot use "0x016x" format as we expect.
It show only %(N) as "0x016x" format, not as "%(N+1)08x%(N)08x".
So I fixed tools/xentrace/formats by using "%(N+1)08x%(N)08x" format.
Also I added some TRC_PV entries.
Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
The reason is that tsc stops and it causes the inaccuracy.
And later we can write some scripts based on this patch.
Signed-off-by: Guanqun Lu <guanqun.lu@intel.com>
If you use -MMD -MF then the correct .o filename is written to the
.*.d file as the compiler driver arranges everything. This was done
in 19010:275abe1c5d24 for the hypervisor.
In this patch we do the same elsewhere in the xen-unstable tree,
particularly tools/. Specifically:
* Change tools/Rules.mk to add -MMD -MF ... to CFLAGS and set DEPS.
* Remove -Wp,-MD... from every other Makefile
* Remove setting of DEPS from every other Makefile
* Ensure that every Makefile says -include $(DEPS)
* Ensure that every Makefile's clean target removes $(DEPS)
Some Makefiles were already halfway there, but often for a different
variable name eg PROG_DEP. The variable name is now standardised in
Rules.mk as DEPS.
I have done a test build with this change, on Debian etch.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This patch fixes the following compilation error caused by
18963:9cc632cc6d40 of xen-unstable.hg
> xenctx.c: In function 'print_ctx':
> xenctx.c:430: error: request for member 'c' in something not a structure or union
> xenctx.c:431: error: 'vcpu_guest_context_any_t' has no member named 'regs'
> xenctx.c:484: error: 'vcpu_guest_context_any_t' has no member named 'event_callback_ip'
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Add support to xenctx for guests that have a different word size
to the tools (x86 only, but shouldn't break ia64). Again, only 32-bit
HVM guests are supported until EFER.LMA is easier to get at.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Xen tracing some times ago used to put values of type 'long' into the
trace buffer. This has changed to uint32_t. Some trace points log
virtual addresses, which get cropped to 32bit in this case. There were
some inline functions to handle at least PF_XEN and VMEXIT, which
caused a lot of code duplication. The attached patch fixes several
issues:
1. fix and extend tools/xentrace/formats
2. Fix xentrace_format to handle up to 7 parameters
3. create convenience macros to properly log long values
4. remove the inline functions in hvm/trace.h and replace them by macros
5. Change the CPUID trace to work correctly
6. group HVM trace points enable mechanism
I used a similar approach as in PV tracing with bit 8 indicating 64bit
pointers.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Before writing records, xentrace will check to make sure that there is
a minimum amount of space left on the output filesystem.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
mb/rmb/wmb. Instead add a xen_ prefix. Modify Xen's public headers to
expect the prefixed names instead of bare mb/rmb/wmb, but gate this
expectation on a bump of __XEN_INTERFACE_VERSION__.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
user-specified polling interval in order to determine when to empty
the trace buffers. Removed the old and unused/unimplemented
new_data_threshold logic.
Signed-off-by: Michael A Fetterman <Michael.Fetterman@cl.cam.ac.uk>
It was previously assert'ing when it hit 4G.
Also, because the trace buffer is not a power of 2 in size,
using modulo arithmetic to address the buffer does not work
when the index wraps around 2^32.
This patch fixes both issues, and as a side effect, removes all
integer division from the hypervisor side of the trace mechanism.
Signed-off-by: Michael A Fetterman <Michael.Fetterman@cl.cam.ac.uk>