Re: [Xen-devel] [PATCH] Plumb through xen-platform device logging

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: 11 July 2013 12:44
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxx
> 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; \
> 
> 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 :-(

> 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);
> 
> 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.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel