[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycl
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem |
Date: |
Mon, 27 Aug 2012 21:22:52 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2012-08-27 21:17, Anthony Liguori wrote:
> Avi Kivity <address@hidden> writes:
>
>> On 08/27/2012 09:24 AM, Anthony Liguori wrote:
>>>>
>>>> I'm sure we should leave existing code alone wherever possible, focusing
>>>> on providing alternative versions for those paths that matter. Example:
>>>> Most timers are fine under BQL. But some sensitive devices (RTC or HPET
>>>> as clock source) will want their own timers. So the approach is to
>>>> instantiate a separate, also prioritizeable instance of the timer
>>>> subsystem for them and be done.
>>>
>>> I disagree. I think we conver the timer subsystem to be lockless and
>>> then let some devices acquire the BQL during dispatch.
>>
>> I agree with your disagreement but disagree with the rest. The timer
>> subsystem should have its own internal locking that callers will not be
>> aware of. Requiring devices to acquire the bql will lead to
>> deadlocks.
>
> Err, I completely mispoke there.
>
> I meant, to say, we should convert the timer subsystem to be re-entrant
> and then let some devices acquire the BQL during dispatch.
>
> Existing users of the time API should get the BQL acquired automagically
> for them. The new API would not hold the BQL during dispatch but the
> old API, implemented in terms of the new API, would acquire it on behalf
> of the caller.
>
> As a rule, if a device relies on the BQL, it must use the old APIs. If
> a device uses the new APIs, it must not acquire the BQL.
This makes sense.
>
>> Note that fine-grained locking timers will also require reference
>> counting: you want to call the timer expiration callback after releasing
>> the timer subsystem lock, so you need to make sure the callback does not
>> go away.
>
> glib simply uses a single main loop lock to deal with all of this. I
> think that's absolutely the right model.
That depends on what is under the lock. Also, relying on locking of
external libraries is a no-go for realtime as they usually do not care
about priorities and inversion avoidance.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, (continued)
Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Anthony Liguori, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Anthony Liguori, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Anthony Liguori, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Anthony Liguori, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem,
Jan Kiszka <=
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Paolo Bonzini, 2012/08/27
Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/08/27
[Qemu-devel] [PATCH 08/10] qdev: rename qdev_unplug to qdev_unplug_req, Liu Ping Fan, 2012/08/24