Re: [Qemu-devel] What's the intended use of log.h logging?

[Denis V. Lunev]

On 10/16/2015 04:00 PM, Paolo Bonzini wrote:
> On 16/10/2015 14:54, Peter Maydell wrote:
> > On 16 October 2015 at 13:48, Paolo Bonzini <address@hidden> wrote:
> > > On 16/10/2015 14:33, Markus Armbruster wrote:
> > > >     Looks like this is basically TCG with a couple of random LOG_UNIMP
> > > >     and LOG_GUEST_ERROR thrown in.  It's definitely not a general purpose
> > > >     QEMU log in its current state.
> > > I think these could become error_report.
> > No; it's important not to print these unless the user really
> > asked for them (especially the GUEST_ERROR) kind. Otherwise it's
> > (potentially quite a lot of) unnecessary noise.
> I guess it depends then.  If the unimplemented feature is in all
> likelihood a showstopper (e.g. setend) it should be unconditionally
> enabled, I think.
>
> > > Some others (e.g. LOG_IOPORT) can be removed.
> > >
> > > LOG_MMU seems to be mostly a ppc thing, could also become a tracepoint.
> > >   Likewise for LOG_PCALL and perhaps LOG_INT.
> > It's also very useful to be able to enable whole *classes* of
> > tracing (like "tell me whenever my guest OS does something dumb");
> > does the tracepoint code have any support for this?
> That's part of what I mentioned in my message ("add some functionality
> to enable tracepoints more easily").  It would be great to have
> something like "-d trace:scsi_*" on the command line, integrated with
> qemu-log.
>
> So perhaps the place of qemu-log is as a replacement for the stderr
> tracing backend?
>
> Paolo

The motivation for the patchset is simple. These messages will be quite
useful to understand how things are going. We do not think about
automatic parsing of that logs at all. They should be human-readable
for us to understand the problem.

In general, we should have "normal" locking engine.

Here I mean a non-blocking facility, which should allow to place
arbitrary log message preserving order of that message in
which events have been happen. In general, this is possible
through lockless ring-buffer and a flush thread. Yes, messages
could be lost if this is noted to the log.

I am a bit old-fashioned with this approach, sorry. This information
is at least necessary to guess what operations were performed
with a VM from outside using conventional interfaces.

Thus my approach to the topic is simple. I'd like to put minimal
information at the moment using current API for 2.5 and expect
this merged if possible,

For 2.6 we will replace the engine with one I have described above.
From my point of view this work should not start new sub-system
but slowly evolve current one.

All bits here a a bit technical without much usage details, but
this is something which should be discussed. With an effective
backend (which does not contradict to the current implementation)
more could be allowed to be logged.

Tracepoints, in general, are designated for the debugging.
Logging is something for post-ship analysis from the customer
report and speaking about [commercially] supported product
running in _production_ you will not be able either to access
customer's host or even customer's network.

Den