On 26 August 2017 at 01:02, Emilio G. Cota wrote:
> An additional "nice to have" would be:
>
> * Allow inlining of TCG code by the instrumenter. Example use case:
> the instrumenter wants to increment a counter every time a
> basic block is executed. Instead of calling a
On Thu, Aug 03, 2017 at 12:54:57 +0100, Stefan Hajnoczi wrote:
> > > Please post an example of the API you'd like.
> >
> > In my opinion, the instrumentation support in this series provides an API
> > that
> > works in the opposite way you're suggesting (let's ignore the fact that it's
> > built
On Fri, Jul 28, 2017 at 19:05:43 +0300, Lluís Vilanova wrote:
> As for the (minimum) requirements I've collected:
>
> * Peek at register values and guest memory.
> * Enumerate guest cpus.
> * Control when events are raised to minimize overheads (e.g., avoid generating
> TCG code to trace a
On Wed, Aug 02, 2017 at 06:19:29PM +0300, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
>
> > On Wed, Aug 02, 2017 at 12:10:14PM +0100, Peter Maydell wrote:
> >> On 2 August 2017 at 12:04, Stefan Hajnoczi wrote:
> >> > On Tue, Aug 01, 2017 at 02:54:29PM +0100, Peter
Stefan Hajnoczi writes:
> On Wed, Aug 02, 2017 at 12:10:14PM +0100, Peter Maydell wrote:
>> On 2 August 2017 at 12:04, Stefan Hajnoczi wrote:
>> > On Tue, Aug 01, 2017 at 02:54:29PM +0100, Peter Maydell wrote:
>> >> and I don't need the TCG engine to be a library to do
On Wed, Aug 02, 2017 at 12:10:14PM +0100, Peter Maydell wrote:
> On 2 August 2017 at 12:04, Stefan Hajnoczi wrote:
> > On Tue, Aug 01, 2017 at 02:54:29PM +0100, Peter Maydell wrote:
> >> and I don't need the TCG engine to be a library to do that...
> >
> > You do need TCG
On 2 August 2017 at 12:04, Stefan Hajnoczi wrote:
> On Tue, Aug 01, 2017 at 02:54:29PM +0100, Peter Maydell wrote:
>> and I don't need the TCG engine to be a library to do that...
>
> You do need TCG APIs if you want TCG-level instrumentation, tuning
> options, callbacks,
On Fri, Jul 28, 2017 at 07:21:04PM +0300, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
>
> > On Thu, Jul 27, 2017 at 11:40:17AM +0100, Peter Maydell wrote:
> >> On 27 July 2017 at 11:32, Stefan Hajnoczi wrote:
> >> > On Wed, Jul 26, 2017 at 03:44:39PM +0300, Lluís
On Tue, Aug 01, 2017 at 02:54:29PM +0100, Peter Maydell wrote:
> On 1 August 2017 at 14:48, Stefan Hajnoczi wrote:
> > Thanks for sharing the requirements. A stable API is necessary for
> > providing these features.
> >
> > We're essentially talking about libqemu. That means
On 1 August 2017 at 14:48, Stefan Hajnoczi wrote:
> Thanks for sharing the requirements. A stable API is necessary for
> providing these features.
>
> We're essentially talking about libqemu. That means QEMU in library
> form with an API for JIT engine, reverse engineering,
On Fri, Jul 28, 2017 at 07:05:43PM +0300, Lluís Vilanova wrote:
> Daniel P Berrange writes:
>
> > On Fri, Jul 28, 2017 at 02:41:19PM +0100, Peter Maydell wrote:
> >> On 28 July 2017 at 14:34, Stefan Hajnoczi wrote:
> >> > Lluís/Peter: What are the requirements for
On Fri, Jul 28, 2017 at 07:14:33PM +0300, Lluís Vilanova wrote:
> Daniel P Berrange writes:
>
> > On Fri, Jul 28, 2017 at 02:34:30PM +0100, Stefan Hajnoczi wrote:
> >> On Thu, Jul 27, 2017 at 04:45:35PM +0100, Daniel P. Berrange wrote:
> >> > On Thu, Jul 27, 2017 at 04:33:01PM +0100, Peter
Stefan Hajnoczi writes:
> On Thu, Jul 27, 2017 at 11:40:17AM +0100, Peter Maydell wrote:
>> On 27 July 2017 at 11:32, Stefan Hajnoczi wrote:
>> > On Wed, Jul 26, 2017 at 03:44:39PM +0300, Lluís Vilanova wrote:
>> >> And why exactly is this a threat? Because it can be used to
Daniel P Berrange writes:
> On Fri, Jul 28, 2017 at 02:34:30PM +0100, Stefan Hajnoczi wrote:
>> On Thu, Jul 27, 2017 at 04:45:35PM +0100, Daniel P. Berrange wrote:
>> > On Thu, Jul 27, 2017 at 04:33:01PM +0100, Peter Maydell wrote:
>> > > On 27 July 2017 at 16:21, Daniel P. Berrange
Daniel P Berrange writes:
> On Fri, Jul 28, 2017 at 02:41:19PM +0100, Peter Maydell wrote:
>> On 28 July 2017 at 14:34, Stefan Hajnoczi wrote:
>> > Lluís/Peter: What are the requirements for instrumentation code
>> > interacting with the running QEMU instance? simpletrace
Stefan Hajnoczi writes:
> On Thu, Jul 27, 2017 at 04:45:35PM +0100, Daniel P. Berrange wrote:
>> On Thu, Jul 27, 2017 at 04:33:01PM +0100, Peter Maydell wrote:
>> > On 27 July 2017 at 16:21, Daniel P. Berrange wrote:
>> > > On Thu, Jul 27, 2017 at 11:54:29AM +0100, Peter
On Fri, Jul 28, 2017 at 02:41:19PM +0100, Peter Maydell wrote:
> On 28 July 2017 at 14:34, Stefan Hajnoczi wrote:
> > Lluís/Peter: What are the requirements for instrumentation code
> > interacting with the running QEMU instance? simpletrace is
> > asynchronous, meaning it
On Fri, Jul 28, 2017 at 02:34:30PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jul 27, 2017 at 04:45:35PM +0100, Daniel P. Berrange wrote:
> > On Thu, Jul 27, 2017 at 04:33:01PM +0100, Peter Maydell wrote:
> > > On 27 July 2017 at 16:21, Daniel P. Berrange wrote:
> > > > On Thu,
On Thu, Jul 27, 2017 at 11:40:17AM +0100, Peter Maydell wrote:
> On 27 July 2017 at 11:32, Stefan Hajnoczi wrote:
> > On Wed, Jul 26, 2017 at 03:44:39PM +0300, Lluís Vilanova wrote:
> >> And why exactly is this a threat? Because it can be used to "extend" QEMU
> >> without
On 28 July 2017 at 14:34, Stefan Hajnoczi wrote:
> Lluís/Peter: What are the requirements for instrumentation code
> interacting with the running QEMU instance? simpletrace is
> asynchronous, meaning it does not wait for anyone handle the trace event
> before continuing
On Thu, Jul 27, 2017 at 04:45:35PM +0100, Daniel P. Berrange wrote:
> On Thu, Jul 27, 2017 at 04:33:01PM +0100, Peter Maydell wrote:
> > On 27 July 2017 at 16:21, Daniel P. Berrange wrote:
> > > On Thu, Jul 27, 2017 at 11:54:29AM +0100, Peter Maydell wrote:
> > >> That said,
Daniel P Berrange writes:
> On Thu, Jul 27, 2017 at 11:54:29AM +0100, Peter Maydell wrote:
>> On 27 July 2017 at 11:43, Daniel P. Berrange wrote:
>> > Maybe I'm missing something, but aren't all these things
>> > already possible via either the statically defined tracepoints
On Thu, Jul 27, 2017 at 04:33:01PM +0100, Peter Maydell wrote:
> On 27 July 2017 at 16:21, Daniel P. Berrange wrote:
> > On Thu, Jul 27, 2017 at 11:54:29AM +0100, Peter Maydell wrote:
> >> That said, yes, I was going to ask if we could do this via
> >> leveraging the
On 27 July 2017 at 16:21, Daniel P. Berrange wrote:
> On Thu, Jul 27, 2017 at 11:54:29AM +0100, Peter Maydell wrote:
>> That said, yes, I was going to ask if we could do this via
>> leveraging the tracepoint infrastructure and whatever scripting
>> facilities it provides. Are
On Thu, Jul 27, 2017 at 11:54:29AM +0100, Peter Maydell wrote:
> On 27 July 2017 at 11:43, Daniel P. Berrange wrote:
> > Maybe I'm missing something, but aren't all these things
> > already possible via either the statically defined tracepoints
> > QEMU exposes, or by placing
Peter Maydell writes:
> On 27 July 2017 at 11:43, Daniel P. Berrange wrote:
>> Maybe I'm missing something, but aren't all these things
>> already possible via either the statically defined tracepoints
>> QEMU exposes, or by placing dynamic tracepoints on arbitrary
>> code
On 27 July 2017 at 11:43, Daniel P. Berrange wrote:
> Maybe I'm missing something, but aren't all these things
> already possible via either the statically defined tracepoints
> QEMU exposes, or by placing dynamic tracepoints on arbitrary
> code locations using
On Wed, Jul 26, 2017 at 12:49:00PM +0100, Peter Maydell wrote:
> On 26 July 2017 at 12:26, Stefan Hajnoczi wrote:
> > On Tue, Jul 25, 2017 at 02:30:06PM +0100, Peter Maydell wrote:
> >> Is your proposal that my-instrumentation.c gets compiled into
> >> QEMU at this point?
On 27 July 2017 at 11:32, Stefan Hajnoczi wrote:
> On Wed, Jul 26, 2017 at 03:44:39PM +0300, Lluís Vilanova wrote:
>> And why exactly is this a threat? Because it can be used to "extend" QEMU
>> without touching its sources? Is this a realistic threat? (it's a rather
>>
On Wed, Jul 26, 2017 at 03:44:39PM +0300, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
>
> > On Tue, Jul 25, 2017 at 06:11:43PM +0300, Lluís Vilanova wrote:
> >> Peter Maydell writes:
> >>
> >> > On 25 July 2017 at 14:19, Stefan Hajnoczi wrote:
> >> >> Instead I suggest
Stefan Hajnoczi writes:
> On Tue, Jul 25, 2017 at 06:11:43PM +0300, Lluís Vilanova wrote:
>> Peter Maydell writes:
>>
>> > On 25 July 2017 at 14:19, Stefan Hajnoczi wrote:
>> >> Instead I suggest adding a trace backend generates calls to registered
>> >> "callback"
Stefan Hajnoczi writes:
> On Tue, Jul 25, 2017 at 05:47:08PM +0300, Lluís Vilanova wrote:
>> Stefan Hajnoczi writes:
>>
>> > On Mon, Jul 24, 2017 at 08:02:24PM +0300, Lluís Vilanova wrote:
>> >> This series adds a basic interface to instrument tracing events and
>> >> control
>> >> their
Peter Maydell writes:
> On 26 July 2017 at 12:26, Stefan Hajnoczi wrote:
>> On Tue, Jul 25, 2017 at 02:30:06PM +0100, Peter Maydell wrote:
>>> Is your proposal that my-instrumentation.c gets compiled into
>>> QEMU at this point? That doesn't seem like a great idea to
>>> me,
On 26 July 2017 at 12:26, Stefan Hajnoczi wrote:
> On Tue, Jul 25, 2017 at 02:30:06PM +0100, Peter Maydell wrote:
>> Is your proposal that my-instrumentation.c gets compiled into
>> QEMU at this point? That doesn't seem like a great idea to
>> me, because it means you can
On Tue, Jul 25, 2017 at 05:47:08PM +0300, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
>
> > On Mon, Jul 24, 2017 at 08:02:24PM +0300, Lluís Vilanova wrote:
> >> This series adds a basic interface to instrument tracing events and control
> >> their tracing state.
> >>
> >> The instrumentation
On Tue, Jul 25, 2017 at 02:30:06PM +0100, Peter Maydell wrote:
> On 25 July 2017 at 14:19, Stefan Hajnoczi wrote:
> > Instead I suggest adding a trace backend generates calls to registered
> > "callback" functions:
> >
> > $ cat >my-instrumentation.c
> > #include
On Tue, Jul 25, 2017 at 06:11:43PM +0300, Lluís Vilanova wrote:
> Peter Maydell writes:
>
> > On 25 July 2017 at 14:19, Stefan Hajnoczi wrote:
> >> Instead I suggest adding a trace backend generates calls to registered
> >> "callback" functions:
> >>
> >> $ cat
Peter Maydell writes:
> On 25 July 2017 at 14:19, Stefan Hajnoczi wrote:
>> Instead I suggest adding a trace backend generates calls to registered
>> "callback" functions:
>>
>> $ cat >my-instrumentation.c
>> #include "trace/control.h"
>>
>> static void my_cpu_in(unsigned
Stefan Hajnoczi writes:
> On Mon, Jul 24, 2017 at 08:02:24PM +0300, Lluís Vilanova wrote:
>> This series adds a basic interface to instrument tracing events and control
>> their tracing state.
>>
>> The instrumentation code is dynamically loaded into QEMU (either when it
>> starts
>> or later
On 25 July 2017 at 14:19, Stefan Hajnoczi wrote:
> Instead I suggest adding a trace backend generates calls to registered
> "callback" functions:
>
> $ cat >my-instrumentation.c
> #include "trace/control.h"
>
> static void my_cpu_in(unsigned int addr, char size, unsigned
On Mon, Jul 24, 2017 at 08:02:24PM +0300, Lluís Vilanova wrote:
> This series adds a basic interface to instrument tracing events and control
> their tracing state.
>
> The instrumentation code is dynamically loaded into QEMU (either when it
> starts
> or later using its remote control
41 matches
Mail list logo