[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


 


Rackspace

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