From: Peter Lieven <pl@kamp.de>
To: Paolo Bonzini <pbonzini@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-stable] Recent patches for 2.4
Date: Thu, 3 Sep 2015 15:11:16 +0200 [thread overview]
Message-ID: <55E846F4.7000506@kamp.de> (raw)
In-Reply-To: <55BB3FE7.3000106@redhat.com>
Am 31.07.2015 um 11:29 schrieb Paolo Bonzini:
>
> On 31/07/2015 10:35, Peter Lieven wrote:
>> Am 31.07.2015 um 10:22 schrieb Paolo Bonzini:
>>>> 52c91da memory: do not add a reference to the owner of aliased regions
>>> This could be backported, yes. Feel free to send it to qemu-stable.
>>> However, the bug was only visible with virtio 1.
>> Applies cleanly to 2.3.1-staging.
> Good.
>
>>>> edec47c main-loop: fix qemu_notify_event for aio_notify optimization
>>> Part of the above AioContext series.
>> So either the whole series or none of them I guess?
> It's a separate bug, and theoretically it's there in 2.3.1 as well, but
> no one ever reproduced it (it would hang in make check) so not worthwhile.
I maybe found another case where this bugfix seems to help. For various
reasons I'm still on 2.2.1 stable with some CVE fixes manually applied.
I currently work on the problem that a haning NFS Server where I mount
my CDROM ISOs from takes down the whole vServer because the main loop
hangs sooner or later.
I already put some patches on the list which help to improve the situation:
ide/atapi: make PIO read requests async
block/io: allow AIOCB without callback
ide/atapi: partially avoid deadlock if the storage backend is dead
block/nfs: cache allocated filesize for read-only files
However, I ended up with one case where Qemu deadlocks in bdrv_drain_one.
Scenario:
- Windows 2012R2 with a random ISO mounted.
- Block communication to NFS via Firewall
- execute 'eject ide1-cd0' in the HMP
- restore connectivity.
The HMP hangs forever even if the NFS connectivity itself is restored.
Peter
next prev parent reply other threads:[~2015-09-03 13:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 8:12 [Qemu-devel] Recent patches for 2.4 Peter Lieven
2015-07-31 8:22 ` Paolo Bonzini
2015-07-31 8:35 ` Peter Lieven
2015-07-31 9:29 ` Paolo Bonzini
2015-08-04 9:22 ` [Qemu-devel] [Qemu-stable] " Peter Lieven
2015-08-04 11:53 ` Paolo Bonzini
2015-08-04 11:57 ` Peter Lieven
2015-08-04 12:09 ` Paolo Bonzini
2015-08-04 12:29 ` Peter Lieven
2015-08-04 12:53 ` Peter Lieven
2015-08-04 23:23 ` ronnie sahlberg
2015-08-05 8:39 ` Paolo Bonzini
2015-08-06 7:51 ` Peter Lieven
2015-09-03 13:11 ` Peter Lieven [this message]
2015-09-07 16:28 ` Paolo Bonzini
2015-09-07 19:11 ` Peter Lieven
2015-09-07 19:14 ` Paolo Bonzini
2015-09-07 21:05 ` Peter Lieven
2015-09-21 7:40 ` Peter Lieven
2015-09-21 9:41 ` Paolo Bonzini
2015-09-21 9:52 ` Peter Lieven
2015-09-21 12:16 ` Paolo Bonzini
2015-08-04 18:20 ` Michael Roth
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=55E846F4.7000506@kamp.de \
--to=pl@kamp.de \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=stefanha@redhat.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).