Re: [Xen-devel] Is: PVH dom0 - MWAIT detection logic to get deeper C-states exposed in ACPI AML code. Was:Re: [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 18/2/16 a les 16:12, Andrew Cooper ha escrit:
> On 18/02/16 15:02, Roger Pau Monné wrote:
>> El 17/2/16 a les 20:02, Konrad Rzeszutek Wilk ha escrit:
>>> On Mon, Feb 15, 2016 at 03:41:41PM +0000, Andrew Cooper wrote:
>>>> On 15/02/16 15:02, Jan Beulich wrote:
>>>>>>>> On 15.02.16 at 15:53, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>>> On 15/02/16 14:50, Jan Beulich wrote:
>>>>>>>>>> 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.)
>>>>>> Yes - the intercepts are always enabled to prevent the guest actually
>>>>>> putting the processor to sleep.
>>>>> Hmm, you're right, somehow I've managed to ignore the relevant
>>>>> lines grep reported. Yet - how do things work then, without the
>>>>> MWAIT feature flag currently getting cleared?
>>>> I have never observed it being used.  Do you have some local patches in
>>>> the SLES hypervisor?
>>>>
>>>> There is some gross layer violation in xen/enlighten.c to pretend that
>>>> MWAIT is present to trick the ACPI code into evaluating _CST() methods
>>>> to report back to Xen.  (This is yet another PV-ism which will cause a
>>>> headache for a DMLite dom0)
>>> Yes indeed. CC-ing Roger, and Boris.
>> Yes, all this is indeed not very nice, and we would ideally like to get
>> rid of it on PVHv2.
>>
>> Could we use the acpica tools (acpidump/acpixtract/acpiexec/...) in
>> order to fetch this information from user-space and send it to Xen using
>> privcmd?
>>
>> AFAIK those tools work on most OSes (or at least the ones we care about
>> as Dom0).
> 
> In general, we can't rely on userspace evaluation of AML.
> 
> For trivial AML which evaluates to a constant, it could be interpreted
> by userspace, but anything accessing system resources will need
> evaluating by the kernel.

Hm, I've took a look at the ACPI tables in one of my systems, and I'm 
not sure, but I guess the CPU related methods indeed must be executed 
by the kernel. I don't have much idea of ASL, but I guess the 
"Register" instruction means that a specific register must be poked, 
and it probably can't be done from user-space:

[...]
    Scope (\_PR.CPU0)
    {
        Name (_PPC, Zero)  // _PPC: Performance Present Capabilities
        Method (_PCT, 0, NotSerialized)  // _PCT: Performance Control
        {
            \_PR.CPU0._PPC = \_PR.CPPC
            If (((CFGD & One) && (PDC0 & One)))
            {
                Return (Package (0x02)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x00,               // Bit Width
                            0x00,               // Bit Offset
                            0x0000000000000000, // Address
                            ,)
                    }, 

                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x00,               // Bit Width
                            0x00,               // Bit Offset
                            0x0000000000000000, // Address
                            ,)
                    }
                })
            }
        }

        Name (_PSS, Package (0x10)  // _PSS: Performance Supported States
        {
            Package (0x06)
            {
                0x00000834, 
                0x00003A98, 
                0x0000000A, 
                0x0000000A, 
                0x00001500, 
                0x00001500
            }, 

            Package (0x06)
            {
                0x000007D0, 
                0x00003708, 
                0x0000000A, 
                0x0000000A, 
                0x00001400, 
                0x00001400
            }, 
[...]

Do we have a formal list of what exactly does Xen want from ACPI that 
it cannot fetch itself?

I'm quite sure Xen cares about all the "Processor Vendor-Specific ACPI" 
[0], that should be _PCT, _CST and _PTC (located in \_PR_.CPUN._XXX).

Roger.

[0] 
http://www.intel.es/content/dam/www/public/us/en/documents/product-specifications/processor-vendor-specific-acpi-specification.pdf

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