[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: |
Thu, 25 Oct 2012 18:28:27 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 |
On 10/24/2012 09:29 AM, Paolo Bonzini wrote:
> Il 23/10/2012 18:09, Avi Kivity ha scritto:
>>> But our interfaces had better support asynchronicity, and indeed they
>>> do: after you write to the "eject" register, the "up" will show the
>>> device as present until after destroy is done. This can be changed to
>>> show the device as present only until after step 4 is done.
>>
>> Let's say we want to eject the hotplug hardware itself (just as an
>> example). With refcounts, the callback that updates "up" will hold on
>> to to it via refcounts. With stop_machine(), you need to cancel that
>> callback, or wait for it somehow, or it can arrive after the
>> stop_machine() and bite you.
>
> The callback that updates "up" is for the parent of the hotplug
> hardware. There is nothing that has to be updated in the hotplug
> hardware itself.
I meant, as an unrealistic example, hot-unplugging the bridge itself.
So we have a callback that updates information in the bridge (up
register state) being called asynchronously.
A more realistic example would be hot-unplug of an HBA, then the block
layer callback comes back to update the device. So stop_machine() would
need to cancel all I/O and wait for I/O that cannot be cancelled.
>
> Updating the "up" register is the final part of isolate(), and runs
> before the stop_machine(). The steps above can be further refined like
> this:
>
> 4a. close all backends (also cancel or complete all pending I/O)
^ long latency
> 4b. notify parent that we're done
> 4ba. parent removes device from its bus
> 4bb. parent notifies guest
> 4bc. parent schedules stop_machine(qdev_free(child))
> 5. a bottom half calls stop_machine(qdev_free(child))
>
> If unplugging a whole sub-tree, the parent can notify its own parent at
> the end of 4b. Because the only purpose of stop_machine is to quiesce
> subsystems not affected by step 4 (timer+memory, typically),
> destructions can be done in any order and even intermixed with
> executions of 4b for the parent.
>
> In the beginning the only asynchronous step would be 5. If the need
> arises we can use continuation-passing to make all the preceding steps
> asynchronous too.
>
Maybe my worry about long stop_machine latencies is premature. Everyone
in the kernel hates it, but the kernel scales a lot more than qemu and
is in a much better place wrt threading.
--
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, 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, Paolo Bonzini, 2012/10/24
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps,
Avi Kivity <=
- Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps, Paolo Bonzini, 2012/10/26
- 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, 2012/10/23
[Qemu-devel] [patch v4 08/16] QemuThread: make QemuThread as tls to store extra info, Liu Ping Fan, 2012/10/22