qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC P


From: Avi Kivity
Subject: Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts""
Date: Tue, 09 Oct 2012 15:21:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

On 10/09/2012 03:11 PM, Paolo Bonzini wrote:
>> But no, it's actually impossible.  Hotplug may be triggered from a vcpu
>> thread, which clearly it can't be stopped.
> 
> Hotplug should always be asynchronous (because that's how hardware
> works), so it should always be possible to delegate the actual work to a
> non-VCPU thread.  Or not?

The actual device deletion can happen from a different thread, as long
as you isolate the device before.  That's part of the garbage collector
idea.

vcpu thread:
  rcu_read_lock
  lookup
  dispatch
    mmio handler
      isolate
      queue(delete_work)
  rcu_read_unlock

worker thread:
  process queue
    delete_work
      synchronize_rcu() / stop_machine()
      acquire qemu lock
      delete object
      drop qemu lock

Compared to the garbage collector idea, this drops fined-grained locking
for the qdev tree, a significant advantage.  But it still suffers from
dispatching inside the rcu critical section, which is something we want
to avoid.

I think refcounting is still the best direction, but maybe we can think
of a new idea here.

-- 
error compiling committee.c: too many arguments to function



reply via email to

[Prev in Thread] Current Thread [Next in Thread]