From: Avi Kivity <avi@redhat.com>
To: Igor Mitsyanko <i.mitsyanko@samsung.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
liu ping fan <qemulist@gmail.com>,
Peter Crosthwaite <peter.crosthwaite@petalogix.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Paolo Bonzini <pbonzini@redhat.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Subject: Re: [Qemu-devel] [PATCH V3 10/11] vcpu: introduce lockmap
Date: Wed, 19 Sep 2012 16:03:29 +0300 [thread overview]
Message-ID: <5059C2A1.4050208@redhat.com> (raw)
In-Reply-To: <5059C221.5060606@samsung.com>
On 09/19/2012 04:01 PM, Igor Mitsyanko wrote:
>>> That would avoid the lockups and allow the device to be reset at
>>> any time. Or am I missing something?
>>>
>> Not that I can see. If real hardware can be looped, so can qemu. I'm
>> only worried about recursion and deadlocks (while real hardware can
>> deadlock, we'd prefer to avoid that).
>>
>>
>
> So, I think the idea here is that if real hardware can be locked we
> should lock too, but provide a guest CPU a possibility to abort locked
> operation. For this particular example, SD card controller can deadlock
> on recursive descriptor LINK entries, but CPU can abort ongoing
> transaction at any time by issuing ABORT command. And if guest CPU
> busy-waits in infinite while() loop for a TRANSFER OVER flag to be set,
> then it had it coming.
If real hardware would lock up so should we (in the guest's eyes) but
the qemu monitor should remain responsive. It is not part of emulated
hardware.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-09-19 13:03 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 7:51 [Qemu-devel] [PATCH V3 0/10] prepare unplug out of protection of global lock Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations Liu Ping Fan
2012-09-11 8:04 ` Avi Kivity
2012-09-13 6:54 ` liu ping fan
2012-09-13 8:14 ` Avi Kivity
2012-09-13 8:19 ` Paolo Bonzini
2012-09-13 8:23 ` Avi Kivity
2012-09-13 8:29 ` Paolo Bonzini
2012-09-13 8:45 ` liu ping fan
2012-09-19 13:16 ` Jamie Lokier
2012-09-19 13:32 ` Jamie Lokier
2012-09-19 14:12 ` Peter Maydell
2012-09-19 15:53 ` Jamie Lokier
2012-09-11 8:15 ` Peter Maydell
2012-09-13 6:53 ` liu ping fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 02/11] qom: apply atomic on object's refcount Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 03/11] hotplug: introduce qdev_unplug_complete() to remove device from views Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 04/11] pci: remove pci device from mem view when unplug Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 05/11] memory: introduce ref, unref interface for MemoryRegionOps Liu Ping Fan
2012-09-11 8:08 ` Avi Kivity
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 06/11] memory: make mmio dispatch able to be out of biglock Liu Ping Fan
2012-09-11 8:25 ` Avi Kivity
2012-09-11 8:47 ` Avi Kivity
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 07/11] memory: implement e1000's MemoryRegionOps ref/unref Liu Ping Fan
2012-09-11 8:37 ` Avi Kivity
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 08/11] qom: introduce reclaimer to release obj in async Liu Ping Fan
2012-09-11 8:32 ` Avi Kivity
2012-09-11 9:32 ` liu ping fan
2012-09-11 9:37 ` Avi Kivity
2012-09-13 6:54 ` liu ping fan
2012-09-13 8:45 ` Avi Kivity
2012-09-13 9:59 ` liu ping fan
2012-09-13 10:09 ` Avi Kivity
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 09/11] vcpu: make QemuThread as tls to store thread-self info Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 10/11] vcpu: introduce lockmap Liu Ping Fan
2012-09-11 8:35 ` Avi Kivity
2012-09-11 9:44 ` liu ping fan
2012-09-11 9:54 ` Avi Kivity
2012-09-11 10:04 ` Jan Kiszka
2012-09-11 11:03 ` Avi Kivity
2012-09-11 11:08 ` Jan Kiszka
2012-09-11 12:20 ` Avi Kivity
2012-09-11 12:25 ` Jan Kiszka
2012-09-11 12:30 ` Avi Kivity
2012-09-11 12:35 ` Jan Kiszka
2012-09-11 12:39 ` Avi Kivity
2012-09-19 4:25 ` Peter Crosthwaite
2012-09-19 4:32 ` Edgar E. Iglesias
2012-09-19 4:40 ` Peter Crosthwaite
2012-09-19 7:55 ` Avi Kivity
2012-09-19 11:46 ` Edgar E. Iglesias
2012-09-19 12:12 ` Avi Kivity
2012-09-19 12:17 ` Edgar E. Iglesias
2012-09-19 13:01 ` Igor Mitsyanko
2012-09-19 13:03 ` Avi Kivity [this message]
2012-09-19 7:57 ` Jan Kiszka
2012-09-19 13:07 ` Igor Mitsyanko
2012-09-11 9:57 ` Jan Kiszka
2012-09-11 12:24 ` Avi Kivity
2012-09-11 12:41 ` Avi Kivity
2012-09-11 14:54 ` Marcelo Tosatti
2012-09-13 6:55 ` liu ping fan
2012-09-13 6:55 ` liu ping fan
2012-09-13 8:19 ` Avi Kivity
2012-09-17 2:24 ` liu ping fan
2012-09-19 8:01 ` Avi Kivity
2012-09-19 8:36 ` liu ping fan
2012-09-19 9:05 ` Avi Kivity
2012-09-20 7:51 ` liu ping fan
2012-09-20 9:15 ` Avi Kivity
2012-09-21 7:27 ` liu ping fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 11/11] vcpu: push mmio dispatcher out of big lock Liu Ping Fan
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=5059C2A1.4050208@redhat.com \
--to=avi@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=edgar.iglesias@gmail.com \
--cc=i.mitsyanko@samsung.com \
--cc=jan.kiszka@siemens.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@petalogix.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.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).