On Thu, Sep 20, 2012 at 5:15 PM, Avi Kivity wrote:
> On 09/20/2012 10:51 AM, liu ping fan wrote:
>> On Wed, Sep 19, 2012 at 5:05 PM, Avi Kivity wrote:
>>> On 09/19/2012 11:36 AM, liu ping fan wrote:
>
> It basically means you can't hold contents of device state in local
> variables.
On 09/20/2012 10:51 AM, liu ping fan wrote:
> On Wed, Sep 19, 2012 at 5:05 PM, Avi Kivity wrote:
>> On 09/19/2012 11:36 AM, liu ping fan wrote:
It basically means you can't hold contents of device state in local
variables. You need to read everything again from the device. That
>>
On Wed, Sep 19, 2012 at 5:05 PM, Avi Kivity wrote:
> On 09/19/2012 11:36 AM, liu ping fan wrote:
>>>
>>> It basically means you can't hold contents of device state in local
>>> variables. You need to read everything again from the device. That
>>> includes things like DMA enable bits.
>>>
>> I t
On 09/19/2012 11:57 AM, Jan Kiszka wrote:
On 2012-09-19 06:40, Peter Crosthwaite wrote:
On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
wrote:
On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote:
Ping for PMM,
This is the root case of your block on the SDHCI series - this is
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 hardwar
On 09/19/2012 04:12 PM, Avi Kivity wrote:
On 09/19/2012 02:46 PM, Edgar E. Iglesias wrote:
On Wed, Sep 19, 2012 at 10:55:30AM +0300, Avi Kivity wrote:
On 09/19/2012 07:40 AM, Peter Crosthwaite wrote:
On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
wrote:
On Wed, Sep 19, 2012 at 02:25:48PM
On Wed, Sep 19, 2012 at 03:12:12PM +0300, Avi Kivity wrote:
> On 09/19/2012 02:46 PM, Edgar E. Iglesias wrote:
> > On Wed, Sep 19, 2012 at 10:55:30AM +0300, Avi Kivity wrote:
> >> On 09/19/2012 07:40 AM, Peter Crosthwaite wrote:
> >> > On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
> >> > wrot
On 09/19/2012 02:46 PM, Edgar E. Iglesias wrote:
> On Wed, Sep 19, 2012 at 10:55:30AM +0300, Avi Kivity wrote:
>> On 09/19/2012 07:40 AM, Peter Crosthwaite wrote:
>> > On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
>> > wrote:
>> >> On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite w
On Wed, Sep 19, 2012 at 10:55:30AM +0300, Avi Kivity wrote:
> On 09/19/2012 07:40 AM, Peter Crosthwaite wrote:
> > On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
> > wrote:
> >> On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote:
> >>> Ping for PMM,
> >>>
> >>> This is the root
On 09/19/2012 11:36 AM, liu ping fan wrote:
>>
>> It basically means you can't hold contents of device state in local
>> variables. You need to read everything again from the device. That
>> includes things like DMA enable bits.
>>
> I think that read everything again from the device can not work
On Wed, Sep 19, 2012 at 4:01 PM, Avi Kivity wrote:
> On 09/17/2012 05:24 AM, liu ping fan wrote:
>> On Thu, Sep 13, 2012 at 4:19 PM, Avi Kivity wrote:
>>> On 09/13/2012 09:55 AM, liu ping fan wrote:
On Tue, Sep 11, 2012 at 8:41 PM, Avi Kivity wrote:
> On 09/11/2012 03:24 PM, Avi Kivity
On 09/17/2012 05:24 AM, liu ping fan wrote:
> On Thu, Sep 13, 2012 at 4:19 PM, Avi Kivity wrote:
>> On 09/13/2012 09:55 AM, liu ping fan wrote:
>>> On Tue, Sep 11, 2012 at 8:41 PM, Avi Kivity wrote:
On 09/11/2012 03:24 PM, Avi Kivity wrote:
> On 09/11/2012 12:57 PM, Jan Kiszka wrote:
>>>
On 2012-09-19 06:40, Peter Crosthwaite wrote:
> On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
> wrote:
>> On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote:
>>> Ping for PMM,
>>>
>>> This is the root case of your block on the SDHCI series - this is a
>>> discussion on resoluti
On 09/19/2012 07:40 AM, Peter Crosthwaite wrote:
> On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
> wrote:
>> On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote:
>>> Ping for PMM,
>>>
>>> This is the root case of your block on the SDHCI series - this is a
>>> discussion on resol
On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
wrote:
> On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote:
>> Ping for PMM,
>>
>> This is the root case of your block on the SDHCI series - this is a
>> discussion on resolution to bogus infinite looping DMA. For current
>> partic
On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote:
> Ping for PMM,
>
> This is the root case of your block on the SDHCI series - this is a
> discussion on resolution to bogus infinite looping DMA. For current
> participants in this discussion, heres our thread on the same topic
> o
Ping for PMM,
This is the root case of your block on the SDHCI series - this is a
discussion on resolution to bogus infinite looping DMA. For current
participants in this discussion, heres our thread on the same topic
over in SD land:
http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01017.
On Thu, Sep 13, 2012 at 4:19 PM, Avi Kivity wrote:
> On 09/13/2012 09:55 AM, liu ping fan wrote:
>> On Tue, Sep 11, 2012 at 8:41 PM, Avi Kivity wrote:
>>> On 09/11/2012 03:24 PM, Avi Kivity wrote:
On 09/11/2012 12:57 PM, Jan Kiszka wrote:
> On 2012-09-11 11:44, liu ping fan wrote:
>>
On 09/13/2012 09:55 AM, liu ping fan wrote:
> On Tue, Sep 11, 2012 at 8:41 PM, Avi Kivity wrote:
>> On 09/11/2012 03:24 PM, Avi Kivity wrote:
>>> On 09/11/2012 12:57 PM, Jan Kiszka wrote:
On 2012-09-11 11:44, liu ping fan wrote:
> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
>>
On Tue, Sep 11, 2012 at 8:41 PM, Avi Kivity wrote:
> On 09/11/2012 03:24 PM, Avi Kivity wrote:
>> On 09/11/2012 12:57 PM, Jan Kiszka wrote:
>>> On 2012-09-11 11:44, liu ping fan wrote:
On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
>>
On Tue, Sep 11, 2012 at 10:54 PM, Marcelo Tosatti wrote:
> On Tue, Sep 11, 2012 at 03:41:15PM +0300, Avi Kivity wrote:
>> On 09/11/2012 03:24 PM, Avi Kivity wrote:
>> > On 09/11/2012 12:57 PM, Jan Kiszka wrote:
>> >> On 2012-09-11 11:44, liu ping fan wrote:
>> >>> On Tue, Sep 11, 2012 at 4:35 PM,
On Tue, Sep 11, 2012 at 03:41:15PM +0300, Avi Kivity wrote:
> On 09/11/2012 03:24 PM, Avi Kivity wrote:
> > On 09/11/2012 12:57 PM, Jan Kiszka wrote:
> >> On 2012-09-11 11:44, liu ping fan wrote:
> >>> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
> On 09/11/2012 10:51 AM, Liu Ping Fan w
On 09/11/2012 03:24 PM, Avi Kivity wrote:
> On 09/11/2012 12:57 PM, Jan Kiszka wrote:
>> On 2012-09-11 11:44, liu ping fan wrote:
>>> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> The func call chain can su
On 09/11/2012 03:35 PM, Jan Kiszka wrote:
> On 2012-09-11 14:30, Avi Kivity wrote:
>>> The other option is to keep DMA requests issued by devices synchronous
>>> but let them fail if we are about to lock up. Still requires changes,
>>> but is probably more comprehensible for device mode
On 2012-09-11 14:30, Avi Kivity wrote:
>> The other option is to keep DMA requests issued by devices synchronous
>> but let them fail if we are about to lock up. Still requires changes,
>> but is probably more comprehensible for device model developers.
>
> How do you handle fai
On 09/11/2012 03:25 PM, Jan Kiszka wrote:
Most DMA today happens without the big qemu lock. We only need to
convert the paths that actually access memory, these are the block and
network layers (for the respective devices).
>>>
>>> ...and the devices themselves, of course.
>>
On 2012-09-11 14:20, Avi Kivity wrote:
> On 09/11/2012 02:08 PM, Jan Kiszka wrote:
>> On 2012-09-11 13:03, Avi Kivity wrote:
>>> On 09/11/2012 01:04 PM, Jan Kiszka wrote:
>>>
> DMA is inherently asynchronous, so we already drop the lock between
> initiation and completion; we need to find a
On 09/11/2012 12:57 PM, Jan Kiszka wrote:
> On 2012-09-11 11:44, liu ping fan wrote:
>> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
>>> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
From: Liu Ping Fan
The func call chain can suffer from recursively hold
qemu_mutex_lock_io
On 09/11/2012 02:08 PM, Jan Kiszka wrote:
> On 2012-09-11 13:03, Avi Kivity wrote:
>> On 09/11/2012 01:04 PM, Jan Kiszka wrote:
>>
DMA is inherently asynchronous, so we already drop the lock between
initiation and completion; we need to find a way to make it easy to use
the API with
On 2012-09-11 13:03, Avi Kivity wrote:
> On 09/11/2012 01:04 PM, Jan Kiszka wrote:
>
>>> DMA is inherently asynchronous, so we already drop the lock between
>>> initiation and completion; we need to find a way to make it easy to use
>>> the API without taking the lock while the transfer takes plac
On 09/11/2012 01:04 PM, Jan Kiszka wrote:
>> DMA is inherently asynchronous, so we already drop the lock between
>> initiation and completion; we need to find a way to make it easy to use
>> the API without taking the lock while the transfer takes place.
>
> We will have to review/rework device m
On 2012-09-11 11:54, Avi Kivity wrote:
> On 09/11/2012 12:44 PM, liu ping fan wrote:
>> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
>>> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
From: Liu Ping Fan
The func call chain can suffer from recursively hold
qemu_mutex_lock_io
On 2012-09-11 11:44, liu ping fan wrote:
> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
>> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> The func call chain can suffer from recursively hold
>>> qemu_mutex_lock_iothread. We introduce lockmap to record the
>>> loc
On 09/11/2012 12:44 PM, liu ping fan wrote:
> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
>> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> The func call chain can suffer from recursively hold
>>> qemu_mutex_lock_iothread. We introduce lockmap to record the
>>>
On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> The func call chain can suffer from recursively hold
>> qemu_mutex_lock_iothread. We introduce lockmap to record the
>> lock depth.
>
> What is the root cause? io handlers
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> The func call chain can suffer from recursively hold
> qemu_mutex_lock_iothread. We introduce lockmap to record the
> lock depth.
What is the root cause? io handlers initiating I/O?
Perhaps we can have a solution that is loca
From: Liu Ping Fan
The func call chain can suffer from recursively hold
qemu_mutex_lock_iothread. We introduce lockmap to record the
lock depth.
Signed-off-by: Liu Ping Fan
---
cpus.c | 18 ++
qemu-thread-posix.c | 23 +++
qemu-thread-posix.
37 matches
Mail list logo
