From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2] KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates Date: Tue, 08 Dec 2009 16:07:32 +0200 Message-ID: <4B1E5DA4.3010605@redhat.com> References: <4B1BE216.2090407@web.de> <4B1BE452.6090107@redhat.com> <4B1BE8BF.7030404@web.de> <20091208140249.GA19154@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm , Gleb Natapov To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31683 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755366AbZLHOH1 (ORCPT ); Tue, 8 Dec 2009 09:07:27 -0500 In-Reply-To: <20091208140249.GA19154@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 12/08/2009 04:02 PM, Marcelo Tosatti wrote: > On Sun, Dec 06, 2009 at 06:24:15PM +0100, Jan Kiszka wrote: > >> User space may not want to overwrite asynchronously changing VCPU event >> states on write-back. So allow to skip nmi.pending and sipi_vector by >> setting corresponding bits in the flags field of kvm_vcpu_events. >> >> Signed-off-by: Jan Kiszka >> > Can't you handle this in userspace entirely, only updating vcpu_events > state when appropriate? > For what we do now I think you're right, it can be handled in userspace. But in general, there's currently no way to update vcpu_events without overwriting nmi and sipi_vector, which can also be written concurrently by other vcpus. So there's a hole in the interface. > Shouldnt the vcpu be stopped in the first place, when its state is > updated? > It is stopped, but other vcpus are not. -- error compiling committee.c: too many arguments to function