From: Cornelia Huck <cohuck@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: pasic@linux.ibm.com, zhang.zhanghailiang@huawei.com,
kvm@vger.kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org,
AlexChen <alex.chen@huawei.com>,
borntraeger@de.ibm.com, qemu-s390x@nongnu.org, chenhc@lemote.com,
zhengchuan@huawei.com
Subject: Re: [PATCH 0/4] kvm: Add a --enable-debug-kvm option to configure
Date: Wed, 28 Oct 2020 09:20:08 +0100 [thread overview]
Message-ID: <20201028092008.5a5397fc.cohuck@redhat.com> (raw)
In-Reply-To: <404f58a5-180d-f3d7-dbcc-b533a29e6a94@redhat.com>
On Wed, 28 Oct 2020 08:44:59 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 28/10/20 08:11, AlexChen wrote:
> > The current 'DEBUG_KVM' macro is defined in many files, and turning on
> > the debug switch requires code modification, which is very inconvenient,
> > so this series add an option to configure to support the definition of
> > the 'DEBUG_KVM' macro.
> > In addition, patches 3 and 4 also make printf always compile in debug output
> > which will prevent bitrot of the format strings by referring to the
> > commit(08564ecd: s390x/kvm: make printf always compile in debug output).
>
> Mostly we should use tracepoints, but the usefulness of these printf
> statements is often limited (except for s390 that maybe could make them
> unconditional error_reports). I would leave this as is, maintainers can
> decide which tracepoints they like to have.
Looking at the s390 statements, they look more like something to put
into trace events (the "unimplemented instruction" cases are handled
gracefully, but the information might be interesting when developing.)
next prev parent reply other threads:[~2020-10-28 8:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5F97FD61.4060804@huawei.com>
2020-10-28 7:11 ` [PATCH 0/4] kvm: Add a --enable-debug-kvm option to configure AlexChen
2020-10-28 7:44 ` Paolo Bonzini
2020-10-28 8:20 ` Cornelia Huck [this message]
2020-10-29 6:13 ` AlexChen
[not found] ` <5F991331.4020604@huawei.com>
2020-10-28 7:11 ` [PATCH 1/4] configure: " AlexChen
2020-10-28 7:11 ` [PATCH 2/4] kvm: Replace DEBUG_KVM with CONFIG_DEBUG_KVM AlexChen
[not found] ` <5F9914EE.8050209@huawei.com>
2020-10-28 7:11 ` [PATCH 3/4] kvm: make printf always compile in debug output AlexChen
[not found] ` <5F991641.4050606@huawei.com>
2020-10-28 7:11 ` [PATCH 4/4] i386/kvm: " AlexChen
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=20201028092008.5a5397fc.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.chen@huawei.com \
--cc=borntraeger@de.ibm.com \
--cc=chenhc@lemote.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=zhang.zhanghailiang@huawei.com \
--cc=zhengchuan@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).