From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wright Subject: KVM call minutes for May 25 Date: Tue, 25 May 2010 07:59:48 -0700 Message-ID: <20100525145948.GC29293@x200.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: qemu-devel@nongnu.org To: kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16753 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932290Ab0EYO7v (ORCPT ); Tue, 25 May 2010 10:59:51 -0400 Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: Generic Asynchronous task offloading - keep vcpu thread from blocking - generic approach is useful, comes down to specifics - e.g. what is done in worker threads, how locking is handled - offload blocking work to worker threads - need to make device model reentrant - can be simple w/ lock per device, but needs finer grained to be perfromant - but needs - thread pool should be relatively easy to merge - two alternatives for virtfs - one full request in thread, one that does syscalls asynchronously - need to have something demonstrably better to make threading acceptable - complexity of state machine vs. locking - performance difference at the end (e.g. coarse grained locking doesn't fully allow for parallel execution) - lapic needs to be reentrant - in qemu lapic should show off the benefit very well - hpet would also benefit from being threaded - multiple threads per device (needs device specific locking) - qxl, scsi, virtfs... - push global lock down to pio/mmio dispatch - audit for global qemu state changes done w/in device - anthony will set up wiki page to describe making device models reentrant - looking for volunteers!