From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH RFC v12 08/21] pvh: vmx-specific changes Date: Fri, 20 Sep 2013 14:07:48 +0100 Message-ID: <523C48A4.20906@eu.citrix.com> References: <1379089521-25720-1-git-send-email-george.dunlap@eu.citrix.com> <1379089521-25720-9-git-send-email-george.dunlap@eu.citrix.com> <5239D3F802000078000F46A3@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VN0RA-0003rG-NG for xen-devel@lists.xenproject.org; Fri, 20 Sep 2013 13:07:56 +0000 In-Reply-To: <5239D3F802000078000F46A3@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser , Eddie Dong , Jun Nakajima , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 18/09/13 15:25, Jan Beulich wrote: >>>> On 13.09.13 at 18:25, George Dunlap wrote: >> +static int pvh_check_requirements(struct vcpu *v) >> +{ >> + u64 required, tmpval = real_cr4_to_pv_guest_cr4(mmu_cr4_features); >> + >> + if ( !paging_mode_hap(v->domain) ) >> + { >> + printk(XENLOG_G_INFO "HAP is required for PVH guest.\n"); >> + return -EINVAL; >> + } >> + if ( !cpu_has_vmx_ept ) >> + { >> + printk(XENLOG_G_INFO "PVH: CPU does not have EPT support\n"); >> + return -ENOSYS; > While I realize that this was that was perhaps in what you took > from Mukesh, I think this and similar uses of -ENOSYS are > misguided; -EOPNOTSUPP would seem more appropriate. > >> + /* PVH: I don't think these are necessary */ >> + v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_NMI_PENDING; >> + vmentry_ctl &= ~VM_ENTRY_LOAD_GUEST_EFER; > Particularly these two would be nice to be confirmed by our VMX > maintainers, who you should have Cc-ed. Doing a bit more investigation, it looks like the NMI_PENDING thing was probably because Mukesh's duplicated vmexit handler didn't (yet) do the work of setting and clearing this when necessary. Since we're using the shared vmexit code now, that's all sorted out. In any case, I'm pretty sure it starts out cleared, and is set in vmx/intr.c:enable_intr_window(). -George