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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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().
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel