From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 10/11] VMX: work around lacking VNMI support Date: Thu, 25 Sep 2008 11:41:23 +0200 Message-ID: <48DB5CC3.5010104@siemens.com> References: <48D74CE6.5060008@siemens.com> <48D7504B.7050102@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "Yang, Sheng" , Gleb Natapov , kvm-devel To: Avi Kivity Return-path: Received: from gecko.sbs.de ([194.138.37.40]:16947 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752963AbYIYJlp (ORCPT ); Thu, 25 Sep 2008 05:41:45 -0400 In-Reply-To: <48D7504B.7050102@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: ... > Index: b/arch/x86/kvm/vmx.c > =================================================================== > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -90,6 +90,11 @@ struct vcpu_vmx { > } rmode; > int vpid; > bool emulation_required; > + > + /* Support for vnmi-less CPUs */ > + int soft_vnmi_blocked; > + ktime_t entry_time; > + s64 vnmi_blocked_time; I meanwhile realized that these states (except entry_time) and probably also arch.nmi_pending/injected are things that should be considered when the vcpu state is saved and restored, right? What is the right interface for this? An extension of kvm_sregs? BTW, via which channel is GUEST_INTERRUPTIBILITY_INFO from the vmcs saved/restored? I'm currently not seeing any related, CPU-specific code. For NMI code, the virtual blocking bit would be relevant (if the CPU supports it, of course), but I guess the other bits are also important enough to let them survive. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux