From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state Date: Tue, 17 Nov 2009 15:28:29 +0200 Message-ID: <4B02A4FD.4010802@redhat.com> References: <4B018542.3020602@siemens.com> <4B01A487.3020808@redhat.com> <4B01C2B0.3000205@web.de> <4B02592C.6060004@redhat.com> <4B025B50.4070505@web.de> <4B0260D7.1060107@redhat.com> <4B026A03.4080600@web.de> <4B0298F0.3080007@redhat.com> <4B029FA8.5080205@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32190 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751891AbZKQN2Y (ORCPT ); Tue, 17 Nov 2009 08:28:24 -0500 In-Reply-To: <4B029FA8.5080205@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 11/17/2009 03:05 PM, Jan Kiszka wrote: > >> Problem is, the inject channels are implied (APIC messages in smp >> guests). Documentation is good, but if we can avoid it that's better. >> >> Note the only way to rmw vcpu events during smp is pausing the guest, >> because of this race. >> > That's what qemu does on reset and load. > These aren't rmw. > The alternative would be a complex get&lock/put&unlock + a queue for > async events during the lock + an option to ignore what was queued when > doing a true reset. Back to square #1: we would still need the proposed > high-level interface to communicate the difference between replay and > drop queue. > There's no need for get+lock / put+unlock; a normal get/put with the addition that get flushes the queue suffices. To make sure queued events don't affect set you need to stop the entire VM before setting state, but you need to do that anyway for non-rmw writes. -- error compiling committee.c: too many arguments to function