[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps |
Date: |
Tue, 23 Oct 2012 16:37:55 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 |
On 10/23/2012 02:40 PM, Jan Kiszka wrote:
> On 2012-10-23 14:28, Avi Kivity wrote:
>> On 10/23/2012 02:16 PM, Jan Kiszka wrote:
>>> On 2012-10-23 14:12, Paolo Bonzini wrote:
>>>> Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>>>>>>>>>
>>>>>>>>> So the stop_machine idea is thrown away?
>>>>>>>
>>>>>>> IIRC I convinced myself that it's just as bad.
>>>>> One tricky part with stop machine is that legacy code may trigger it
>>>>> while holding the BQL, does not expect to lose that lock even for a
>>>>> brief while, but synchronizing on other threads does require dropping
>>>>> the lock right now. Maybe an implementation detail, but at least a nasty
>>>>> one.
>>>>
>>>> But it would only be triggered by hot-unplug, no?
>>>
>>> Once all code that adds/removes memory regions from within access
>>> handlers is converted.
>>
>> add/del is fine. memory_region_destroy() is the problem. I have
>> patches queued that fix those problems and add an assert() to make sure
>> we don't add more.
>>
>> It's not just memory regions, it's practically anything that can be
>> removed and that has callbacks. The two proposals are:
>>
>> - qomify
>> - split unplug into isolate+destroy
>> - let the issuer of the callbacks manage the reference counts
>
> What do you mean with the last one?
Call ref/unref as needed (this patchset).
Here, "the issuer of the callbacks" is the memory core. For timer
callbacks, it is the timer subsystem.
>
>>
>> vs
>>
>> - split unplug into isolate+destroy
>> - let unplug defer destruction to a bottom half, and stop_machine there
>> - if we depend on the results [1], add a continuation
>>
>> [1] Say a monitor command wants to return only after the block device
>> has been detached from qemu
>
> The monitor is likely harmless (as it's pretty confined). But is that
> all? Hunting down all (corner) cases will make switching to this model
> tricky.
That is my feeling as well. The first model requires more work, but is
complete. The second model is easier, but we may run into a wall if we
find a case it doesn't cover.
--
error compiling committee.c: too many arguments to function
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, (continued)
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Avi Kivity, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Paolo Bonzini, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Avi Kivity, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Paolo Bonzini, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Avi Kivity, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Jan Kiszka, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Paolo Bonzini, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Jan Kiszka, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Avi Kivity, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Jan Kiszka, 2012/10/23
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps,
Avi Kivity <=
[Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Liu Ping Fan, 2012/10/22
- Re: [Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Jan Kiszka, 2012/10/22
- Re: [Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Peter Maydell, 2012/10/22
- Re: [Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, liu ping fan, 2012/10/23
- Re: [Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Paolo Bonzini, 2012/10/23
- Re: [Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Peter Maydell, 2012/10/23
- Re: [Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Jan Kiszka, 2012/10/23
- Re: [Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Paolo Bonzini, 2012/10/23
- Re: [Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Peter Maydell, 2012/10/23
[Qemu-devel] [patch v4 12/16] e1000: apply fine lock on e1000, Liu Ping Fan, 2012/10/22