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 10:37:43 +0200 Message-ID: <4B0260D7.1060107@redhat.com> References: <4B018542.3020602@siemens.com> <4B01A487.3020808@redhat.com> <4B01C2B0.3000205@web.de> <4B02592C.6060004@redhat.com> <4B025B50.4070505@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]:58033 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754682AbZKQIhi (ORCPT ); Tue, 17 Nov 2009 03:37:38 -0500 In-Reply-To: <4B025B50.4070505@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 11/17/2009 10:14 AM, Jan Kiszka wrote: > > >> state that is updated outside the vcpu thread. These are particularly >> bad since we can't exclude them from updates without excluding other >> state as well. >> > We easily can, using the very same mechanism: No need to overwrite any > of the kvm_vcpu_events during runtime, only on reset/vmload). > That's because qemu has no need for this. But kvm is more than just serving qemu, we try to be more general. That said, I can't really see anyone wanting to arbitrarily inject an exception. >> The whole issue is tricky. I'm inclined to pretend we never meant any >> vcpu state (outside lapic) to be asynchronous and declare the whole >> thing a bug. We could fix it by modeling external changes to state >> (INIT, SIPI, NMI) as messages queued to the vcpu, to be processed in the >> vcpu thread. The queue would be drained before running the vcpu or >> before reading state from userspace, so the message queue contents can >> never be observed and never lost. >> >> Of course, we can't really implement this as a queue (SIGSTOP vcpu >> thread -> overflow), but a word is sufficient. INIT writes the word, >> everything else uses compare-and-swap or set_bit to raise events (e.g. >> SIPI = do { oldq = vcpu->queue; newq = (oldq& ~SIPI_MASK) | sipi_vector >> | RUNNING; } while (!cas(&vcpu->queue, oldq, newq))) >> >> > I do not yet see why we need this complication, why the proposed model > isn't enough. > The current interface is subtly dangerous, you can't run set(get()) as you would expect. (well you can't with the lapic or the tsc msr either...) -- error compiling committee.c: too many arguments to function