From: Don Slutz <dslutz@verizon.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] Plumb through xen-platform device logging
Date: Thu, 11 Jul 2013 08:28:56 -0400 [thread overview]
Message-ID: <51DEA508.8080603@terremark.com> (raw)
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0060AA7@LONPEX01CL01.citrite.net>
On 07/11/13 08:07, Paul Durrant wrote:
>> -----Original Message-----
>> From: Ian Campbell [mailto:ian.campbell@citrix.com]
>> Sent: 11 July 2013 12:44
>> To: Paul Durrant
>> Cc: xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] [PATCH] Plumb through xen-platform device logging
>>
>> On Thu, 2013-07-11 at 08:23 +0000, Paul Durrant wrote:
>>>> diff --git a/tools/Makefile b/tools/Makefile
>>>> index e44a3e9..2d791a4 100644
>>>> --- a/tools/Makefile
>>>> +++ b/tools/Makefile
>>>> @@ -202,7 +202,8 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
>>>> --disable-kvm \
>>>> --disable-docs \
>>>> --python=$(PYTHON) \
>>>> - $(IOEMU_CONFIGURE_CROSS); \
>>>> + $(IOEMU_CONFIGURE_CROSS) \
>>>> + --enable-trace-backend=stderr; \
I have done this in a more flexable way:
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -187,8 +185,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
source=.; \
fi; \
cd qemu-xen-dir; \
- $$source/configure --enable-xen --target-list=i386-softmmu \
- --prefix=$(PREFIX) \
+ $$source/configure --enable-xen $(QEMU_UPSTREAM_EXTRA_CONFIG)
--target-list=i386-softmmu \
--source-path=$$source \
--extra-cflags="-I$(XEN_ROOT)/tools/include \
-I$(XEN_ROOT)/tools/libxc \
I.E by adding QEMU_UPSTREAM_EXTRA_CONFIG which I add to .config when I
want to turn on tracing.
>> Is this the only way to do this?
>>
>> It is likely that many distros will use their standard qemu packages
>> which may or may not have this option enabled.
>>
> That's true.
>
>> I'm not sure if this is a static always on option or if this is simply
>> making a trace backend available for use.
>>
> It's a static selection as far as I can tell. The tracing backend is not selectable at runtime :-(
It is static and adds a lot of code. So you want a way to not configure
it also. However what trace output happens is changeable while running.
>> Looking at http://wiki.qemu.org/Features/Tracing is the tracing
>> interface really the right way to be logging this particular class of
>> information? I'd have thought a simple logfile support in the platform
>> device would be a much more natural fit.
>>
> That makes sense to me, but whoever coded up the platform device obviously believed tracing to be the correct way to log. I don't know the history of that decision.
> It doesn't change the fact though that, currently, xen builds of QEMU don't configure any form of tracing backend at all which doesn't seem particularly helpful, and I did introduce platform logging as an example of an event to log so I think the patch is useful as far as it goes, but maybe another patch to the platform device in QEMU would also be considered a good idea.
>
> Paul
>
>>>> $(MAKE) all
>>>>
>>>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>>>> index 2924298..35f71cc 100644
>>>> --- a/tools/libxl/libxl_dm.c
>>>> +++ b/tools/libxl/libxl_dm.c
>>>> @@ -370,6 +370,13 @@ static char **
>>>> libxl__build_device_model_args_new(libxl__gc *gc,
>>>> "-xen-domid",
>>>> libxl__sprintf(gc, "%d", guest_domid), NULL);
>>>>
>>>> + flexarray_vappend(dm_args,
>>>> + "-trace",
>>>> + libxl__sprintf(gc,
>>>> + "events=%s/qemu-trace-events",
>>>> + libxl__xen_config_dir_path()),
>>>> + NULL);
I handle this by adjusting device_model_args_hvm like:
device_model_args_hvm = [ "-trace", "events=/etc/xen/qemu-trace-events" ]
in the config.
>> Doesn't this end up logging to /etc/xen? Not what we want I think.
>>
>> or maybe this is just the config file, which, apart from my comments
>> about the suitability of the interface above, makes me wonder where the
>> logs do go? Ideally they would go to /var/log/xen/qemu-blah-name.log not
>> to xl stdout.
>>
Using --enable-trace-backend=stderr, the output ends up in
/var/log/xen/qemu-dm-P-1-0.log
I.E. where all stderr from qemu does.
-Don Slutz
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-07-11 12:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 15:33 [PATCH] Plumb through xen-platform device logging Paul Durrant
2013-07-11 8:23 ` Paul Durrant
2013-07-11 11:43 ` Ian Campbell
2013-07-11 12:07 ` Paul Durrant
2013-07-11 12:25 ` Don Slutz
2013-07-11 12:28 ` Don Slutz [this message]
2013-07-11 13:15 ` Paul Durrant
2013-07-11 12:50 ` Ian Campbell
2013-07-11 13:54 ` Anthony PERARD
2013-07-11 13:59 ` Paul Durrant
2013-07-11 14:01 ` Ian Campbell
2013-07-11 14:49 ` Paul Durrant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51DEA508.8080603@terremark.com \
--to=dslutz@verizon.com \
--cc=Ian.Campbell@citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.