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, 15 Dec 2009 16:50:11 +0200 Message-ID: <4B27A223.1050706@redhat.com> References: <4B1BE216.2090407@web.de> <4B1BE452.6090107@redhat.com> <4B1BE8BF.7030404@web.de> <20091208140249.GA19154@amt.cnet> <4B1E5DA4.3010605@redhat.com> <20091208205240.GA24565@amt.cnet> <4B1EC252.9040009@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; 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]:25537 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757699AbZLOOuO (ORCPT ); Tue, 15 Dec 2009 09:50:14 -0500 In-Reply-To: <4B1EC252.9040009@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 12/08/2009 11:17 PM, Jan Kiszka wrote: > >> I don't see the need for setting any state in kvm_vcpu_events >> automatically, on kernel entry (apparently there was consensus that >> saving similar state explicitly in qemu was the way to go). >> > (I don't think so. IMHO the cleaner way is to avoid loading critical > states unless we are resetting or vmloading.) > > I now agree. But instead of SCOPE_RESET and SCOPE_RUNTIME (or whatever that was), how about SCOPE_GPR, SCOPE_FPU, SCOPE_SREGS etc. That means the backing code in kvm.c doesn't have to know what qemu is interested in wrt SCOPE_RESET, and it's easier for readers to infer what is meant. >> kvm_arch_put_registers in qemu saves mpstate now that way, >> and the same problem is present. >> >> The sites to load vcpu_events would be machine reset and cpu_load >> only, right? >> > That is how qemu use it, currently. But this interface should be > designed with more flexibility. For the (yet theoretical) case you want > to update RIP of a single VCPU, you also have to reset all the > context-related states but maybe not the asynchronously changing ones > like nmi.pending. We have no such use case yet, but KVM should not > prevent them by design (if the change is so trivial). > > Yes. -- error compiling committee.c: too many arguments to function