On 16/10/2015 14:54, Peter Maydell wrote:
> On 16 October 2015 at 13:48, Paolo Bonzini <pbonz...@redhat.com> 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
