: Mike Cui
Cc: Peter Turschmid
Cc: Prerna Saxena
Cc: Raphael Norwitz
Cc: Swapnil Ingle
Cc: Ani Sinha
Signed-off-by: Philippe Mathieu-Daudé
---
One Reviewed-by/Ack-by from someone from this domain
should be sufficient to get this patch merged.
An
Hello,
This is my first patch submission. I am interested in the block filter project
for this round of Outreachy.
diff --git a/backends/hostmem.c b/backends/hostmem.c
index 89feb9e..f056a25 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -263,7 +263,7 @@ host_memory_backend_memory
From 9e25fdf1ea3e4f52a72bfefc053a701989b7af24 Mon Sep 17 00:00:00 2001
From: Prerna Garg
Date: Wed, 12 Apr 2017 01:29:40 +0530
Subject: [PATCH 2/2] Changed malloc and free to g_malloc and g_free in
util/compatfd.c
Signed-off-by: Prerna Garg
---
util/compatfd.c | 4 ++--
1 file changed, 2
From f3ee3cf9b69aca86c78ec26468a0b4533744cdad Mon Sep 17 00:00:00 2001
From: Prerna Garg
Date: Wed, 12 Apr 2017 02:04:36 +0530
Subject: [PATCH 3/3] Changed malloc and free to g_malloc and g_free
respectively in util/envlist.c file
Signed-off-by: Prerna Garg
---
util/envlist.c | 22
From: Prerna Garg
Sent: Tuesday, April 11, 2017 9:57 PM
To: Kevin Wolf
Subject: Re: First contribution - Interested in Outreachy
Hello,
I am having difficulties sending the email through command line. So as a last
resort I am sending the patch as an
csi_get_error(iscsi));
____
From: Prerna Garg
Sent: Tuesday, April 11, 2017 12:51 AM
To: qemu-devel@nongnu.org
Cc: stefa...@redhat.com; kw...@redhat.com; Alberto Garcia
Subject: First contribution - Interested in Outreachy
Hello,
This is my first patch submission.
come in.
As for use of this approach with get_features, we have already debated that on
the list before :
https://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg00689.html
To quote:
"I do not entirely agree with that. The first set_mem_table command is not much
different from subsequent set_mem_table calls."
Regards,
Prerna
> I still think it's the right thing to do, but
>> > tests have been failing sporadically.
>> >
>> > Revert for now, and hope to fix it before the release.
>> >
>> > Cc: Prerna Saxena
>> > Cc: Peter Maydell
>> > Cc: Marc-André
Ack. You beat me to the patch by a few minutes :)
Prerna
On 15/08/16 7:05 pm, "Michael S. Tsirkin" wrote:
>This reverts commit 28ed5ef16384f12500abd3647973ee21b03cbe23.
>
>I still think it's the right thing to do, but
>tests have been failing sporadically.
>
On 14/08/16 8:21 am, "Michael S. Tsirkin" wrote:
>On Fri, Aug 12, 2016 at 07:16:34AM +, Prerna Saxena wrote:
>>
>> On 12/08/16 12:08 pm, "Fam Zheng" wrote:
>>
>>
>>
>>
>>
>> >On Wed, 08/10 18:30, Michael S
On 12/08/16 12:08 pm, "Fam Zheng" wrote:
>On Wed, 08/10 18:30, Michael S. Tsirkin wrote:
>> From: Prerna Saxena
>>
>> The set_mem_table command currently does not seek a reply. Hence, there is
>> no easy way for a remote application to notify to QEMU
On 04/08/16 9:41 am, "Michael S. Tsirkin" wrote:
>On Sat, Jul 30, 2016 at 06:38:23AM +, Prerna Saxena wrote:
>>
>>
>>
>>
>>
>> On 30/07/16 2:19 am, "Eric Blake" wrote:
>>
>> >On 07/28/2016 01:07 AM, Prerna
From: Prerna Saxena
This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
If negotiated, client applications should send a u64 payload in
response to any message that contains the "need_reply" bit set
on the message flags. Setting the payload to "zero" indicates the
command f
From: Prerna Saxena
[ This series incorporates all suggestions around documentation that were
suggested.]
vhost-user: Extend protocol to receive replies on any command.
The current vhost-user protocol requires the client to send reply to only a
few commands. For the remaining commands, it is
From: Prerna Saxena
The set_mem_table command currently does not seek a reply. Hence, there is
no easy way for a remote application to notify to QEMU when it finished
setting up memory, or if there were errors doing so.
As an example:
(1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost
On 30/07/16 2:19 am, "Eric Blake" wrote:
>On 07/28/2016 01:07 AM, Prerna Saxena wrote:
>> From: Prerna Saxena
>>
>> This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
>>
>
>> +
>> +With this protocol extension negotiated, the sender
From: Prerna Saxena
The set_mem_table command currently does not seek a reply. Hence, there is
no easy way for a remote application to notify to QEMU when it finished
setting up memory, or if there were errors doing so.
As an example:
(1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost
From: Prerna Saxena
This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
If negotiated, client applications should send a u64 payload in
response to any message that contains the "need_reply" bit set
on the message flags. Setting the payload to "zero" indicates the
command f
From: Prerna Saxena
*** BLURB HERE ***
vhost-user: Extend protocol to receive replies on any command.
The current vhost-user protocol requires the client to send reply to only a
few commands. For the remaining commands, it is impossible for QEMU to know the
status of the requested operation
On 27/07/16 7:00 pm, "Michael S. Tsirkin" wrote:
>On Wed, Jul 27, 2016 at 02:52:37AM -0700, Prerna Saxena wrote:
>> From: Prerna Saxena
>>
>> The set_mem_table command currently does not seek a reply. Hence, there is
>> no easy way for a remote applicati
From: Prerna Saxena
The set_mem_table command currently does not seek a reply. Hence, there is
no easy way for a remote application to notify to QEMU when it finished
setting up memory, or if there were errors doing so.
As an example:
(1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost
From: Prerna Saxena
vhost-user: Extend protocol to receive replies on any command.
The current vhost-user protocol requires the client to send reply to only a
few commands. For the remaining commands, it is impossible for QEMU to know the
status of the requested operation -- ie, did it succeed
From: Prerna Saxena
This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
If negotiated, client applications should send a u64 payload in
response to any message that contains the "need_reply" bit set
on the message flags. Setting the payload to "zero" indicates the
command f
Pl ignore the above series, sending a new revision.
On Thu, Jul 28, 2016 at 11:52 AM, Prerna Saxena
wrote:
> From: Prerna Saxena
>
>
> vhost-user: Extend protocol to receive replies on any command.
>
> The current vhost-user protocol requires the client to send reply to onl
On 27/07/16 6:58 pm, "Michael S. Tsirkin" wrote:
>On Wed, Jul 27, 2016 at 12:56:18PM +, Prerna Saxena wrote:
>> Hi Marc,
>> Thanks, please find my reply inline.
>>
>>
>>
>>
>>
>> On 27/07/16 4:35 pm, "Marc-André L
From: Prerna Saxena
This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
If negotiated, client applications should send a u64 payload in
response to any message that contains the "need_reply" bit set
on the message flags. Setting the payload to "zero" indicates the
command f
From: Prerna Saxena
vhost-user: Extend protocol to receive replies on any command.
The current vhost-user protocol requires the client to send reply to only a
few commands. For the remaining commands, it is impossible for QEMU to know the
status of the requested operation -- ie, did it succeed
From: Prerna Saxena
The set_mem_table command currently does not seek a reply. Hence, there is
no easy way for a remote application to notify to QEMU when it finished
setting up memory, or if there were errors doing so.
As an example:
(1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost
Hi Marc,
Thanks, please find my reply inline.
On 27/07/16 4:35 pm, "Marc-André Lureau" wrote:
>Hi
>
>On Wed, Jul 27, 2016 at 1:52 PM, Prerna Saxena wrote:
>> From: Prerna Saxena
>>
>> This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
>>
>&g
On 27/07/16 9:51 am, "Michael S. Tsirkin" wrote:
>On Mon, Jul 25, 2016 at 02:27:18PM +0400, Marc-André Lureau wrote:
>> Hi
>>
>> On Mon, Jul 25, 2016 at 10:41 AM, Prerna wrote:
>> >
>> >
>> > On Thu, Jul 7, 2016 at 12:04 PM,
From: Prerna Saxena
*** BLURB HERE ***
vhost-user: Extend protocol to receive replies on any command.
The current vhost-user protocol requires the client to send responses to only a
few commands. For the remaining commands, it is impossible for QEMU to know the
status of the requested
From: Prerna Saxena
This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
If negotiated, client applications should send a u64 payload in
response to any message that contains the "need_response" bit set
on the message flags. Setting the payload to "zero" indicates
From: Prerna Saxena
The set_mem_table command currently does not seek a reply. Hence, there is
no easy way for a remote application to notify to QEMU when it finished
setting up memory, or if there were errors doing so.
As an example:
(1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost
Hi Marc,
Thank you for taking a look.
On 25/07/16 3:57 pm, "Marc-André Lureau" wrote:
>Hi
>
>On Mon, Jul 25, 2016 at 10:41 AM, Prerna wrote:
>>
>>
>> On Thu, Jul 7, 2016 at 12:04 PM, Prerna Saxena
>> wrote:
>>>
>>> From: Prerna
On Thu, Jul 7, 2016 at 12:04 PM, Prerna Saxena
wrote:
> From: Prerna Saxena
>
> The current vhost-user protocol requires the client to send responses to
> only a
> few commands. For the remaining commands, it is impossible for QEMU to
> know the
> status of the requested op
From: Prerna Saxena
The set_mem_table command currently does not seek a reply. Hence, there is
no easy way for a remote application to notify to QEMU when it finished
setting up memory, or if there were errors doing so.
As an example:
(1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost
From: Prerna Saxena
This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
If negotiated, client applications should send a u64 payload in
response to any message that contains the "need_response" bit set
on the message flags. Setting the payload to "zero" indicates
From: Prerna Saxena
The current vhost-user protocol requires the client to send responses to only a
few commands. For the remaining commands, it is impossible for QEMU to know the
status of the requested operation -- ie, did it succeed? If so, by what time?
This is inconvenient, and can also
Hi Michael,
Thank you for taking a look.
On 04/07/16 5:29 pm, "Michael S. Tsirkin" wrote:
>On Fri, Jul 01, 2016 at 02:46:20AM -0700, Prerna Saxena wrote:
>> From: Prerna Saxena
>>
>> The current vhost-user protocol requires the client to send responses to
Hi Marc-Andre,
Thank you for taking a look.
On 03/07/16 5:17 pm, "Marc-André Lureau" wrote:
>Hi
>
>On Fri, Jul 1, 2016 at 11:46 AM, Prerna Saxena wrote:
>> From: Prerna Saxena
>>
>> The current vhost-user protocol requires the client to send respons
From: Prerna Saxena
This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK.
If negotiated, client applications should send a u64 payload in
response to any message that contains the "need_response" bit set
on the message flags. Setting the payload to "zero" indicates
From: Prerna Saxena
The current vhost-user protocol requires the client to send responses to only a
few commands. For the remaining commands, it is impossible for QEMU to know the
status of the requested operation -- ie, did it succeed? If so, by what time?
This is inconvenient, and can also
From: Prerna Saxena
The set_mem_table command currently does not seek a reply. Hence, there is
no easy way for a remote application to notify to QEMU when it finished
setting up memory, or if there were errors doing the so.
As an example:
(1) Qemu sends a SET_MEM_TABLE to the backend (eg, a
On 26/06/16 8:15 am, "Michael S. Tsirkin" wrote:
>On Sat, Jun 25, 2016 at 03:13:54AM +, Prerna Saxena wrote:
>>
>>
>>
>>
>>
>> On 25/06/16 4:43 am, "Michael S. Tsirkin" wrote:
>>
>> >On Fri, Jun 24, 2016 a
On 25/06/16 4:43 am, "Michael S. Tsirkin" wrote:
>On Fri, Jun 24, 2016 at 05:39:31PM +, Prerna Saxena wrote:
>>
>>
>> On 24/06/16 9:15 pm, "Felipe Franciosi" wrote:
>>
>> >We talked to MST on IRC a while back and he brainstor
he
NEED_RESPONSE flag bit for all outgoing messages — basically enforcing the
vhost-user application to respond to all messages.
>
>On 24/06/2016, 14:59, "Qemu-devel on behalf of Marc-André Lureau"
>marcandre.lur...@gmail.com> wrote:
>
>Hi
>
>On Fri, Jun 24, 2016
CC'ing MarcAndre and Michael S Tsirkin.
On Fri, Jun 24, 2016 at 1:47 PM, Prerna Saxena
wrote:
> From: Prerna Saxena
>
> Signed-off-by: Prerna Saxena
> ---
> docs/specs/vhost-user.txt | 36 +++
> hw/virtio/vhost-user.c| 153
> +
CC'ing MarcAndre & Michael S Tsirkin.
On Fri, Jun 24, 2016 at 1:47 PM, Prerna Saxena
wrote:
> From: Prerna Saxena
>
> The current vhost-user protocol requires the client to send responses to
> only few commands. For the remaining commands, it is impossible for QEMU to
>
From: Prerna Saxena
Signed-off-by: Prerna Saxena
---
docs/specs/vhost-user.txt | 36 +++
hw/virtio/vhost-user.c| 153 +-
2 files changed, 186 insertions(+), 3 deletions(-)
diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost
From: Prerna Saxena
The current vhost-user protocol requires the client to send responses to only
few commands. For the remaining commands, it is impossible for QEMU to know the
status of the requested operation -- ie, did it succeed at all, and if so, at
what time.
This is inconvenient, and
Hi Eric,
Thank you for the review.
On Wed, Apr 27, 2016 at 9:30 PM, Eric Blake wrote:
> On 04/14/2016 09:02 PM, Prerna Saxena wrote:
> > Qemu code has abort() calls in various places which raises a SIGABRT;
> > This patch adds error messages before (most)calls to abort(), so
Qemu code has abort() calls in various places which raises a SIGABRT;
This patch adds error messages before (most)calls to abort(), so that
it is easier to determine why QEMU died.
Signed-off-by: Prerna Saxena
---
block.c| 1 +
block/block-backend.c | 4
block/curl.c
precede calls to abort().
Prerna Saxena (2):
Block: Cleanup vvfat.c to remove dead code.
Debug : Add error messages before a call to debug().
block.c| 1 +
block/block-backend.c | 4
block/curl.c | 1 +
block/io.c | 1 +
block/linux-aio.c | 1
Commit 43dc2a64 replaced assert() with abort(), but didnt remove statements
that followed these calls. So current code still has return values set after
a call to abort(). Such statements will never execute and need to be cleaned
up.
Signed-off-by: Prerna Saxena
---
block/vvfat.c | 17
On 08/08/2013 04:04 PM, Andreas Färber wrote:
> Am 08.08.2013 09:26, schrieb Prerna Saxena:
>>
>> From: Prerna Saxena
>> Date: Thu, 8 Aug 2013 06:38:03 +0530
>> Subject: [PATCH 2/2] Enhance CPU nodes of device tree to be PAPR compliant.
>>
>> This is based
From: Prerna Saxena
Date: Thu, 8 Aug 2013 06:38:03 +0530
Subject: [PATCH 2/2] Enhance CPU nodes of device tree to be PAPR compliant.
This is based on patch from Andreas which enables the default CPU with KVM
to show up as "-cpu ", such as "POWER7_V2.3@0"
While this
t;POWER7_V2.3@0".
Tested-by: Prerna Saxena
Signed-off-by: Andreas Färber
---
hw/ppc/spapr.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 16bfab9..59e2fea 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1072,7 +1
/2 : Make the device-tree CPU nodes PAPR-compliant.
Changelog from v2:
PATCH 1/2 : Reworked and augmented by Andres Farber against original posted by
Prerna.
PATCH 2/2 : New.
Regards,
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
On 08/01/2013 06:32 AM, Andreas Färber wrote:
> By default on KVM or when user asks for it via -cpu host, cpu_model will
> be "host" and sPAPR merely upper-cases it for the SLOF device tree.
>
> Change it so that we get the underlying CPU type, e.g., "POWER7_V2.3@0
Hi Andreas,
Thanks for the response.
On 07/08/2013 10:15 PM, Andreas Färber wrote:
> Hi,
>
> Am 08.07.2013 17:49, schrieb Prerna Saxena:
>> On 07/08/2013 02:32 PM, Andreas Färber wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>
optimization level is turned down, so that it doesn't
>> recognize that the kvm_enabled() is always false, then this could
>> attempt to compile the ppc asm instructions on an x86 (or
>> whatever) host.
>
> This hunk can be completely replaced by QOM mechanisms - jus
Hi David,
Thanks for the review feedback. I have incorporated your changes in v2 of
the patch, which follows herewith.
Regards,
Prerna
Subject: [PATCH v2] Target-ppc : Enhance the CPU node labels for the guest
device tree for pseries.
In absence of a -CPU parameter in the qemu command line
evice-tree/cpus/PowerPC,POWER7@0/...
/proc/device-tree/cpus/PowerPC,POWER7@4/...
This also helps userspace tools like ppc64_cpu, which expect the device tree
to be in this format in the guest.
Signed-off-by: Prerna Saxena
---
hw/ppc/spapr.c | 17 ++---
target-ppc
Hi Andreas,
Thank you for taking a look.
I have incorporated your feedback into a new patch, attached herewith.
Regards,
Prerna
Subject: [PATCH] target-ppc: Add POWER8 v1.0 CPU model
This patch adds CPU PVR definition for POWER8,
and enables QEMU to launch guests on POWER8 hardware.
Signed
user to -net tap ? )
I'm presently aware of these; it would be good to get more inputs on
what more can be done here.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
;'open_flags': %d }",
bs->device_name, type, bs->removable,
-bs->locked);
+bs->locked, bs->open_flags);
if (bs->drv) {
QObject *obj;
--
1.7.2.3
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
user_print = monitor_user_noop,
+.mhandler.cmd_new = do_set_cache,
+},
+STEXI
+@item set_cache
+@findex set_cache
+Set cache options for a block device.
+ETEXI
{
.name = "acl_show",
.args_type = "aclname:s",
--
1.7.2.3
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
)set_cache ide0-hd0
presently errors out. Ideally, it should display current cache setting
for the given device ide0-hd0
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
the full build
path for defining the probe point. Eg,
probe qemu.qemu_malloc =
process("/Path/to/build/dir/bin/qemu").mark("qemu_malloc") { .. }
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
On 10/22/2010 08:57 PM, Stefan Hajnoczi wrote:
On Thu, Oct 21, 2010 at 03:10:18PM +0530, Prerna Saxena wrote:
trace-event : QMP interface to change state of a trace-event.
(Analogous to hmp command : trace-event )
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 32
: to display currently set trace file and its status.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
trace-event : QMP interface to change state of a trace-event.
(Analogous to hmp command : trace-event )
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
'query-trace-file' : QMP interface to find currently set trace file and
its status.
(Analogous to hmp command : trace-file)
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/qmp-command
set-trace-file : QMP command to:
- Enable/disable logging traces to file
- Set a new output file
- Flush a semi-filled trace-buffer to output file.
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 41 +
1 files changed, 41 insertions
'query-trace-events' : QMP interface to display currently available
trace-events with their state.
( Analogous to hmp command : info trace-events )
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 32
1 files changed, 32 insertions(+), 0 deletion
QMP interface "query-trace" to list current contents of trace-buffer.
( Analogous to hmp command : info trace )
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 51 +++
1 files changed, 51 insertions(+), 0 deletions(-)
diff -
Thanks for the review!
On 10/21/2010 12:53 AM, Luiz Capitulino wrote:
On Wed, 20 Oct 2010 15:28:49 +0530
Prerna Saxena wrote:
QMP command trace-event to toggle state of a trace-event.
Illustration :
-> { "execute": "trace-event", "arguments": { "
Hi Luiz,
Thanks for your feedback.
On 10/21/2010 12:47 AM, Luiz Capitulino wrote:
On Tue, 19 Oct 2010 11:57:50 +0530
Prerna Saxena wrote:
[PATCH 2/2] Add documentation for QMP commands:
- query-trace
- query-trace-events
- query-trace-file.
Please, split this. Each command should be
7;ll post the final version as a part of
the cumulative QMP patchset for tracing ( including patches for query-*
commands posted earlier :
http://lists.gnu.org/archive/html/qemu-devel/2010-10/msg01232.html )
Signed-off-by: Prerna Saxena
---
hmp-commands.hx |2 +-
monitor.c
On 10/19/2010 11:57 AM, Prerna Saxena wrote:
[PATCH 2/2] Add documentation for QMP commands:
- query-trace
- query-trace-events
- query-trace-file.
I've been trying ways to avoid building this documentation for other
trace backends ( since these commands are only available wit
[PATCH 2/2] Add documentation for QMP commands:
- query-trace
- query-trace-events
- query-trace-file.
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 94 +++
1 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/qmp
[PATCH 1/2] Introduce QMP interfaces :
- query-trace
- query-trace-events
- query-trace-file
Signed-off-by: Prerna Saxena
---
monitor.c | 53 ---
simpletrace.c | 69 +
simpletrace.h
:
- Add 'timestamp' field for query-trace output.
- Misc cleanups.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
On 10/18/2010 07:51 PM, Luiz Capitulino wrote:
On Mon, 18 Oct 2010 11:36:55 +0530
Prerna Saxena wrote:
This patch set introduces two QMP interfaces for tracing :
* query-trace: to list current contents of trace-buffer
* query-trace-events : to list all available trace-events with
[PATCH 2/2] Add documentation for QMP commands: query-trace &
query-trace-events.
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 71 +++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-command
[PATCH 1/2] Introduce QMP interfaces : query-trace & query-trace-events.
Signed-off-by: Prerna Saxena
---
monitor.c | 40 +++---
simpletrace.c | 58 +
simpletrace.h |4 +++
3 files changed
and
st_print_trace_events_to_qlist() to return QList*
Changes v1 -> v2 :
- Add 'timestamp' field for query-trace output.
- Misc cleanups.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
[PATCH 2/2] Add documentation for QMP commands: query-trace &
query-trace-events.
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 71 +++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-command
[PATCH 1/2] Introduce QMP interfaces : query-trace & query-trace-events
Signed-off-by: Prerna Saxena
---
monitor.c | 46 +---
simpletrace.c | 58 +
simpletrace.h |4 +++
3 files cha
ut.
- Misc cleanups.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
[PATCH 2/2] Add documentation for QMP commands: query-trace &
query-trace-events.
Signed-off-by: Prerna Saxena
---
qmp-commands.hx | 53 +
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-command
[PATCH 1/2] Introduce QMP interfaces : query-trace & query-trace-events
Signed-off-by: Prerna Saxena
---
monitor.c | 46 ++
simpletrace.c | 54 ++
simpletrace.h |2 ++
3 files cha
This patch set introduces two QMP interfaces for tracing :
* query-trace: to list current contents of trace-buffer
* query-trace-events : to list all available trace-events with their state.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
[PATCH] Add -trace file FILENAME switch to qemu startup command.
This processes the argument using QemuOptsList
Signed-off-by: Prerna Saxena
---
qemu-config.c | 18 ++
qemu-config.h |3 +++
vl.c |5 -
3 files changed, 25 insertions(+), 1 deletions
[PATCH 2/2] Trace event for tracking entry point of balloon request handler.
Signed-off-by: Prerna Saxena
---
balloon.c|2 ++
trace-events |4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/balloon.c b/balloon.c
index 8e0b7f1..0021fef 100644
--- a/balloon.c
[PATCH 1/2] Trace events for tracking port IO
Signed-off-by: Prerna Saxena
---
ioport.c |7 +++
trace-events |4
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/ioport.c b/ioport.c
index 53dd87a..ec3dc65 100644
--- a/ioport.c
+++ b/ioport.c
@@ -26,6 +26,7
Set of patches to add trace-events for tracking IO and balloon events
flagged via the monitor.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
uintptr_t, and then to uint64_t to bypass warnings.
Signed-off-by: Prerna Saxena
---
simpletrace.c | 41 ++---
simpletrace.h | 13 +++--
simpletrace.py |2 +-
tracetool |6 +++---
4 files changed, 37 insertions(+), 25 deletions(-)
diff
This patch adds few more trace events for tracking IO and also to trace
balloon event flagged via the monitor.
Signed-off-by: Prerna Saxena
---
balloon.c|2 ++
ioport.c |7 +++
trace-events |8
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a
trace_args="$trace_args, $(cast_args_to_ulong "$1")"
+trace_args="$trace_args, $(cast_args_to_uint64_t "$1")"
fi
cat<
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
1 - 100 of 152 matches
Mail list logo
