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 16:25:22 +0200 Message-ID: <4B02B252.5080207@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> <4B02A4FD.4010802@redhat.com> <4B02AF58.4010407@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58330 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752494AbZKQOZS (ORCPT ); Tue, 17 Nov 2009 09:25:18 -0500 In-Reply-To: <4B02AF58.4010407@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 11/17/2009 04:12 PM, Jan Kiszka wrote: >> >>> 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 >> > You need to track when to queue and when to apply directly. Call it lock > or call it something else. > You always queue. When starting vcpu_run() or reading state to userspace you flush the queue. The hardware equivalent is posting APIC messages, and the core executing them. >> 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. >> >> > Well, sounds good, but it will be a non-trivial change in the interface > semantics. At bare minimum, we would need a new mp_state interface. If > we would count mp_state to our new event structure (hmm...), then we > could confine the semantical changes to that new IOCTL pair. But how to > deal with existing KVM kernels with their mp_state interface? It's a bit > like the vcpu state thing: we are already down a specific road, and it's > hard to turn around. > I think we're not on the same page here. As I see it, no interface change is needed at all. It's true that existing kernels don't handle this properly, which is why I said I'm willing to treat it as a bug (and thus the -stable treatment etc.). I admit it's a stretch since this is not going to be trivial (though I think less complex that you believe). Putting mp_state into the events structure is reasonable regardless of this issue (and doable since we haven't pushed it to 2.6.33 yet). But I want to understand why you think it's needed. -- error compiling committee.c: too many arguments to function