Stefan Hajnoczi writes:
> 2011/12/8 Lluís Vilanova :
>> Stefan Hajnoczi writes:
>> [...]
* Support for tracing guest code through TCG.
>>
>>> I'm not clear on whether a backdoor mechanism is needed or not. A
>>> backdoor mechanism allows a modified guest to participate in tracing.
>>
>>> D
2011/12/8 Lluís Vilanova :
> Stefan Hajnoczi writes:
> [...]
>>> * Support for tracing guest code through TCG.
>
>> I'm not clear on whether a backdoor mechanism is needed or not. A
>> backdoor mechanism allows a modified guest to participate in tracing.
>
>> Depending on the type of analysis you
Blue Swirl writes:
> 2011/12/8 Lluís Vilanova :
>> Stefan Hajnoczi writes:
>> [...]
* Support for tracing guest code through TCG.
>>
>>> I'm not clear on whether a backdoor mechanism is needed or not. A
>>> backdoor mechanism allows a modified guest to participate in tracing.
>>
>>> Depend
2011/12/8 Lluís Vilanova :
> Stefan Hajnoczi writes:
> [...]
>>> * Support for tracing guest code through TCG.
>
>> I'm not clear on whether a backdoor mechanism is needed or not. A
>> backdoor mechanism allows a modified guest to participate in tracing.
>
>> Depending on the type of analysis you
On Wed, Dec 7, 2011 at 18:54, Anthony Liguori wrote:
> On 12/07/2011 12:51 PM, Peter Maydell wrote:
>>
>> 2011/12/7 Lluís Vilanova:
>>>
>>> Anthony Liguori writes:
>>> [...]
Why should this analyzer live outside of QEMU in the first place? I
fail to see
the rationale for that
Stefan Hajnoczi writes:
[...]
>> * Support for tracing guest code through TCG.
> I'm not clear on whether a backdoor mechanism is needed or not. A
> backdoor mechanism allows a modified guest to participate in tracing.
> Depending on the type of analysis you are doing it might be possible
> to a
2011/12/5 Lluís Vilanova :
> Provides the ability for the guest to communicate with user-provided code
> inside
> QEMU itself, using a lightweight mechanism.
>
> See first commit for a full description.
>
> Signed-off-by: Lluís Vilanova
> ---
First off, thank you for your continued efforts - inc
Lluís Vilanova writes:
[...]
> From my experience, these are the basics I need:
> * Decide what to do when an event is translated (by default - no
> instrumentation
> -, it just generates a TCG call to an execution-time tracing routine).
> This includes:
> * Deciding whether to generate t
Anthony Liguori writes:
> On 12/07/2011 12:51 PM, Peter Maydell wrote:
>> 2011/12/7 Lluís Vilanova:
>>> Anthony Liguori writes:
>>> [...]
Why should this analyzer live outside of QEMU in the first place? I fail
to see
the rationale for that other than not wanting to do the work of
On 12/07/2011 12:51 PM, Peter Maydell wrote:
2011/12/7 Lluís Vilanova:
Anthony Liguori writes:
[...]
Why should this analyzer live outside of QEMU in the first place? I fail to see
the rationale for that other than not wanting to do the work of making it
suitable for upstream consumption.
Fo
2011/12/7 Lluís Vilanova :
> Anthony Liguori writes:
> [...]
>> Why should this analyzer live outside of QEMU in the first place? I fail to
>> see
>> the rationale for that other than not wanting to do the work of making it
>> suitable for upstream consumption.
>
> For the same reason that System
Anthony Liguori writes:
[...]
> Why should this analyzer live outside of QEMU in the first place? I fail to
> see
> the rationale for that other than not wanting to do the work of making it
> suitable for upstream consumption.
For the same reason that SystemTap lets you add user-provided code in
On 12/07/2011 10:59 AM, Lluís Vilanova wrote:
Anthony Liguori writes:
Well, both backdoor and trace instrumentation are implemented using the same
approach (a static library selected at compile-time). The user sets which events
to instrument in the "trace-events" file. This has the effect that t
Anthony Liguori writes:
>> Well, both backdoor and trace instrumentation are implemented using the same
>> approach (a static library selected at compile-time). The user sets which
>> events
>> to instrument in the "trace-events" file. This has the effect that the
>> tracetool
>> script will not
On 12/07/2011 09:23 AM, Lluís Vilanova wrote:
Anthony Liguori writes:
[...]
If you want to extend QEMU, then send proper patches. Adding random C files to
the build is unacceptable.
What do you mean by proper patches?
If you want to add "custom functionality" to QEMU, send a patch to upstr
Anthony Liguori writes:
[...]
>>> If you want to extend QEMU, then send proper patches. Adding random C
>>> files to
>>> the build is unacceptable.
>>
>> What do you mean by proper patches?
> If you want to add "custom functionality" to QEMU, send a patch to upstream
> QEMU.
See below.
>> T
On 12/07/2011 06:21 AM, Lluís Vilanova wrote:
Anthony Liguori writes:
On 12/05/2011 04:22 PM, Lluís Vilanova wrote:
Provides the ability for the guest to communicate with user-provided code inside
QEMU itself, using a lightweight mechanism.
See first commit for a full description.
Signed-off
Anthony Liguori writes:
> On 12/05/2011 04:22 PM, Lluís Vilanova wrote:
>> Provides the ability for the guest to communicate with user-provided code
>> inside
>> QEMU itself, using a lightweight mechanism.
>>
>> See first commit for a full description.
>>
>> Signed-off-by: Lluís Vilanova
> Thi
On 12/05/2011 04:22 PM, Lluís Vilanova wrote:
Provides the ability for the guest to communicate with user-provided code inside
QEMU itself, using a lightweight mechanism.
See first commit for a full description.
Signed-off-by: Lluís Vilanova
This whole series:
Nacked-by: Anthony Liguori
If
Provides the ability for the guest to communicate with user-provided code inside
QEMU itself, using a lightweight mechanism.
See first commit for a full description.
Signed-off-by: Lluís Vilanova
---
Changes in v2:
* Rebase on 1c8a881daaca6fe0646a425b0970fb3ad25f6732 from master.
* Multiple do
20 matches
Mail list logo
