[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset
>>> On 15.02.16 at 15:38, <andrew.cooper3@xxxxxxxxxx> wrote: > On 15/02/16 09:20, Jan Beulich wrote: >>>>> On 12.02.16 at 18:42, <andrew.cooper3@xxxxxxxxxx> wrote: >>> On 12/02/16 17:05, Jan Beulich wrote: >>>>>>> On 05.02.16 at 14:42, <andrew.cooper3@xxxxxxxxxx> wrote: >>>>> #define X86_FEATURE_MWAITX ( 3*32+29) /* MWAIT extension >>> (MONITORX/MWAITX) */ >>>> Why not exposed to HVM (also for _MWAIT as I now notice)? >>> Because that is a good chunk of extra work to support. We would need to >>> use 4K monitor widths, and extra p2m handling. >> I don't understand: The base (_MWAIT) feature being exposed to >> guests today, and kernels making use of the feature when available >> suggests to me that things work. Are you saying you know >> otherwise? (And if there really is a reason to mask the feature all of >> the sudden, this should again be justified in the commit message.) > > PV guests had it clobbered by Xen in traps.c > > HVM guests have: > > vmx.c: > case EXIT_REASON_MWAIT_INSTRUCTION: > case EXIT_REASON_MONITOR_INSTRUCTION: >[...] > hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE); > break; > > and svm.c: > case VMEXIT_MONITOR: > case VMEXIT_MWAIT: > hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE); > break; > > I don't see how a guest could actually use this feature. Do you see the respective intercepts getting enabled anywhere? (I don't outside of nested code, which I didn't check in detail.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |