[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC v12 08/21] pvh: vmx-specific changes

On 18/09/13 15:25, Jan Beulich wrote:
On 13.09.13 at 18:25, George Dunlap <george.dunlap@xxxxxxxxxxxxx> 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().


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.