From: Stefan Weil <weil@mail.berlios.de>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: bernard.blackham@nicta.com.au,
Peter Maydell <peter.maydell@linaro.org>,
Peter Chubb <peter.chubb@nicta.com.au>,
qemu-devel@nongnu.org, philipo@ok-labs.com
Subject: Re: [Qemu-devel] [PATCH] Remove line buffering from log file
Date: Thu, 29 Sep 2011 23:26:46 +0200 [thread overview]
Message-ID: <4E84E296.3070807@mail.berlios.de> (raw)
In-Reply-To: <CAAu8pHv+7dumbYXcHDAWD2GK2HPb7taoKKyrBLUJgvahbYCpMg@mail.gmail.com>
Am 29.09.2011 22:11, schrieb Blue Swirl:
> On Thu, Sep 29, 2011 at 7:57 AM, Peter Maydell
> <peter.maydell@linaro.org> wrote:
>> On 29 September 2011 06:03, Peter Chubb <peter.chubb@nicta.com.au> wrote:
>>> Stefan> That's the reason why line buffering is needed today. I
>>> Stefan> enable log file output to see what happened last before the
>>> Stefan> crash.
>>>
>>> Thanks for this, I didn't think of this use-case. I don't think I've
>>> ever seen a qemu crash that wasn't caused by something really obvious.
>>
>> You don't need the logging for the obvious ones :-)
>>
>>> abort() already flushes all open streams. So only signals that cause
>>> immediate death are a problem: SIGSEGV is the obvious one. If its
>>> handler called abort() then that would flush too. abort() is
>>> guaranteed by the POSIX spec to be callable from a signal handler.
>>
>> Catching SIGSEGV is likely to interact badly with the signal
>> handling in linux-user mode, I expect.
>>
>>> Stefan> Speed is not the primary target when somebody runs qemu -d ...
>>>
>>> It is if it takes hours to reach the problem that causes
>>> the abort(). Speeding up by an order of magnitude is worth it.
>>
>> One tactic I've found useful in these cases is to run without
>> logging up to nearly the point where things fail, and then
>> do a savevm. Then you can loadvm on a qemu with logging enabled
>> and only look at the section of execution that causes the problem.
>
> This sounds like it should be possible to enable and disable logging
> during run time.
The QEMU monitor already supports setting the log level via command 'log'.
I used this command to examine problems with some user commands
running in an emulated Linux.
> The performance could be improved by taking a trace point like
> approach, where all possible processing is postponed to outside
> process. Guest and host code disassembly and op printout could be left
> to postprocessing, the logs should contain only binary data.
prev parent reply other threads:[~2011-09-29 21:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 2:43 [Qemu-devel] [PATCH] Remove line buffering from log file Peter Chubb
2011-09-29 4:47 ` Stefan Weil
2011-09-29 5:03 ` Peter Chubb
2011-09-29 7:57 ` Peter Maydell
2011-09-29 20:11 ` Blue Swirl
2011-09-29 21:26 ` Stefan Weil [this message]
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=4E84E296.3070807@mail.berlios.de \
--to=weil@mail.berlios.de \
--cc=bernard.blackham@nicta.com.au \
--cc=blauwirbel@gmail.com \
--cc=peter.chubb@nicta.com.au \
--cc=peter.maydell@linaro.org \
--cc=philipo@ok-labs.com \
--cc=qemu-devel@nongnu.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 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).