Re: [PATCH-for-5.2 v2] trace: use STAP_SDT_V2 to work around symbol visibility

[Frank Ch. Eigler]

Hi -

> > Maybe add a comment? (no need to repost if you agree):
> >
> ># Workaround to avoid dtrace(1) produces file with 'hidden'
> ># symbol visibility, define STAP_SDT_V2 to produce 'default'
> ># symbol visibility instead.
> >
> > > +QEMU_CFLAGS="$QEMU_CFLAGS -DSTAP_SDT_V2"

Please note that we don't know how long this behavior will persist.
You are relying on an accident. :-)

Much of the systemtap code doesn't support real STAP_SDT_V2 format,
and /usr/include/sys/sdt.h cannot generate it at all.  That macro
tricks only the dtrace-header-generator to suppress the "hidden"
visibility attribute, but doesn't change probe metadata format to the
old V2 (in .probes sections rather than .note.* ELF notes).

We'll try not to break it, but please move toward the more proper
per-solib or per-executable hidden copies of the semaphore objects.

- FChE

Re: [Qemu-devel] [PATCH for-2.0 v2] configure: add workaround for SystemTap PR13296

[Frank Ch. Eigler]

Hi -

On Fri, Mar 21, 2014 at 04:28:24PM +0100, Stefan Hajnoczi wrote:
> SystemTap sdt.h sometimes results in compiled probes without sufficient
> information to extract arguments.  See code comment for details on this
> workaround.
>
> This patch fixes the apic_reset_irq_delivered() trace event on Fedora 20
> with gcc-4.8.2-7.fc20 and systemtap-sdt-devel-2.4-2.fc20 on x86_64.

An alternate solution would focus on this particular trace site.
(It's peculiar because the surrounding code doesn't read the value
being passed to the tracers at all, so the value is not already
available in a register.)

The benefit of this solution is that the hundreds of other trace sites
are not affected at all.  230 of them (on my qemu-system-X86 builds)
use register-indirect operand expressions currently, and your patch
would force all of those to be turned into actual loads -- i.e., slow
down qemu.

Please consider whether that performance is worth it, over a 
patch as dreadful :-) as the following.



diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index c623fcc6d813..e7bbac1be48b 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -117,7 +117,10 @@ void apic_report_irq_delivered(int delivered)
 
 void apic_reset_irq_delivered(void)
 {
-trace_apic_reset_irq_delivered(apic_irq_delivered);
+/* Copy this into a local variable to encourage gcc to emit a plain
+   register for a sys/sdt.h marker. */
+volatile int a_i_d = apic_irq_delivered;
+trace_apic_reset_irq_delivered(a_i_d);
 
 apic_irq_delivered = 0;
 }


- FChE

Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility

[Frank Ch. Eigler]

Hi -

On Tue, Nov 08, 2011 at 11:22:35AM +0100, Ingo Molnar wrote:

> [...]  These examples show *PICTURE PERFECT* forwards ABI
> compatibility, using the ancient perf tool on a bleeding edge
> kernel. [...]

Almost: they demonstrate that those parts of the ABI that these
particular perf commands rely on have been impressively compatible.
Do you have any sort of ABI coverage measurement, to see what
parts of the ABI these perf commands do not use?

- FChE

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Frank Ch. Eigler]

Ingo Molnar  writes:

> [...]
>> It's problem enough that there's no way to know what version of the 
>> perf_event abi you are running against and we have to guess based 
>> on kernel version.  This gets "fun" because all of the vendors have 
>> backported seemingly random chunks of perf_event code to their 
>> older kernels.
>
> The ABI design allows for that kind of flexible extensibility, and 
> it's one of its major advantages.
>
> What we *cannot* protect against is you relying on obscure details of 
> the ABI [...]

Is there some documentation that clearly spells out which parts of the
perf syscall userspace ABI are "obscure" and thus presumably
changeable?

> [...]  The usual ABI rules also apply: we'll revert everything that
> breaks the ABI - but for that you need to report it *in time* [...]

If the ABI is so great in its flexible extensibility, how come it
can't be flexibly extended without having to passing the burden of
compatibility testing & reversion-yawping to someone else?


- FChE

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Frank Ch. Eigler]

$   
From: f...@redhat.com (Frank Ch. Eigler)
Date: Sun, 06 Nov 2011 17:08:48 -0500
In-Reply-To: 
 (Pekka 
Enberg's message of "Sun, 6 Nov 2011 20:05:45 +0200")
Message-ID: 
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Pekka Enberg  writes:

> [...]  We don't want to be different, we want to make the barrier of
> entry low.

When has the barrier of entry into the kernel ever been "low"
for anyone not already working in the kernel?

- FChE

Re: [Qemu-devel] Using the qemu tracepoints with SystemTap

[Frank Ch. Eigler]

Stefan Hajnoczi  writes:

> [...]
> Where are you putting your SystemTap scripts?  I suggest creating a
> public git repo and adding a link from the QEMU wiki tracing page:
> http://wiki.qemu.org/Features/Tracing
>
> Perhaps we could even include them in a contrib/ or similar directory
> in qemu.git so that distros can ship them.  But before we worry about
> that we need a useful set of things that can be observed.

(We can also or instead ship them within systemtap's bundled sources.)

- FChE