From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
boris.ostrovsky@oracle.com
Cc: Jan Beulich <JBeulich@suse.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: 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
Date: Thu, 18 Feb 2016 18:03:59 +0100 [thread overview]
Message-ID: <56C5F97F.7040908@citrix.com> (raw)
In-Reply-To: <56C5DF5F.10200@citrix.com>
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@citrix.com> wrote:
>>>>>> On 15/02/16 14:50, Jan Beulich wrote:
>>>>>>>>>> On 15.02.16 at 15:38, <andrew.cooper3@citrix.com> wrote:
>>>>>>>> On 15/02/16 09:20, Jan Beulich wrote:
>>>>>>>>>>>> On 12.02.16 at 18:42, <andrew.cooper3@citrix.com> wrote:
>>>>>>>>>> On 12/02/16 17:05, Jan Beulich wrote:
>>>>>>>>>>>>>> On 05.02.16 at 14:42, <andrew.cooper3@citrix.com> 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
next prev parent reply other threads:[~2016-02-18 17:03 UTC|newest]
Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 13:41 [PATCH RFC v2 00/30] x86: Improvements to cpuid handling for guests Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 01/30] xen/x86: Drop X86_FEATURE_3DNOW_ALT Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 02/30] xen/x86: Do not store VIA/Cyrix/Centaur CPU features Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 03/30] xen/x86: Drop cpuinfo_x86.x86_power Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 04/30] xen/x86: Improvements to pv_cpuid() Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 05/30] xen/public: Export cpu featureset information in the public API Andrew Cooper
2016-02-12 16:27 ` Jan Beulich
2016-02-17 13:08 ` Andrew Cooper
2016-02-17 13:34 ` Jan Beulich
2016-02-19 17:29 ` Joao Martins
2016-02-19 17:55 ` Andrew Cooper
2016-02-19 22:03 ` Joao Martins
2016-02-20 16:17 ` Andrew Cooper
2016-02-20 17:39 ` Joao Martins
2016-02-20 19:17 ` Andrew Cooper
2016-02-22 18:50 ` Joao Martins
2016-02-05 13:41 ` [PATCH v2 06/30] xen/x86: Script to automatically process featureset information Andrew Cooper
2016-02-12 16:36 ` Jan Beulich
2016-02-12 16:43 ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 07/30] xen/x86: Collect more cpuid feature leaves Andrew Cooper
2016-02-12 16:38 ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 08/30] xen/x86: Mask out unknown features from Xen's capabilities Andrew Cooper
2016-02-12 16:43 ` Jan Beulich
2016-02-12 16:48 ` Andrew Cooper
2016-02-12 17:14 ` Jan Beulich
2016-02-17 13:12 ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 09/30] xen/x86: Store antifeatures inverted in a featureset Andrew Cooper
2016-02-12 16:47 ` Jan Beulich
2016-02-12 16:50 ` Andrew Cooper
2016-02-12 17:15 ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset Andrew Cooper
2016-02-12 17:05 ` Jan Beulich
2016-02-12 17:42 ` Andrew Cooper
2016-02-15 9:20 ` Jan Beulich
2016-02-15 14:38 ` Andrew Cooper
2016-02-15 14:50 ` Jan Beulich
2016-02-15 14:53 ` Andrew Cooper
2016-02-15 15:02 ` Jan Beulich
2016-02-15 15:41 ` Andrew Cooper
2016-02-17 19:02 ` Is: PVH dom0 - MWAIT detection logic to get deeper C-states exposed in ACPI AML code. Was:Re: " Konrad Rzeszutek Wilk
2016-02-17 19:58 ` Boris Ostrovsky
2016-02-18 15:02 ` Roger Pau Monné
2016-02-18 15:12 ` Andrew Cooper
2016-02-18 16:24 ` Boris Ostrovsky
2016-02-18 16:48 ` Andrew Cooper
2016-02-18 17:03 ` Roger Pau Monné [this message]
2016-02-18 22:08 ` Konrad Rzeszutek Wilk
2016-02-18 15:16 ` David Vrabel
2016-02-05 13:42 ` [PATCH v2 11/30] xen/x86: Calculate maximum host and guest featuresets Andrew Cooper
2016-02-15 13:37 ` Jan Beulich
2016-02-15 14:57 ` Andrew Cooper
2016-02-15 15:07 ` Jan Beulich
2016-02-15 15:52 ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 12/30] xen/x86: Generate deep dependencies of features Andrew Cooper
2016-02-15 14:06 ` Jan Beulich
2016-02-15 15:28 ` Andrew Cooper
2016-02-15 15:52 ` Jan Beulich
2016-02-15 16:09 ` Andrew Cooper
2016-02-15 16:27 ` Jan Beulich
2016-02-15 19:07 ` Andrew Cooper
2016-02-16 9:54 ` Jan Beulich
2016-02-17 10:25 ` Andrew Cooper
2016-02-17 10:42 ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 13/30] xen/x86: Clear dependent features when clearing a cpu cap Andrew Cooper
2016-02-15 14:53 ` Jan Beulich
2016-02-15 15:33 ` Andrew Cooper
2016-02-15 14:56 ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 14/30] xen/x86: Improve disabling of features which have dependencies Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 15/30] xen/x86: Improvements to in-hypervisor cpuid sanity checks Andrew Cooper
2016-02-15 15:43 ` Jan Beulich
2016-02-15 17:12 ` Andrew Cooper
2016-02-16 10:06 ` Jan Beulich
2016-02-17 10:43 ` Andrew Cooper
2016-02-17 10:55 ` Jan Beulich
2016-02-17 14:02 ` Andrew Cooper
2016-02-17 14:45 ` Jan Beulich
2016-02-18 12:17 ` Andrew Cooper
2016-02-18 13:23 ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 16/30] x86/cpu: Move set_cpumask() calls into c_early_init() Andrew Cooper
2016-02-16 14:10 ` Jan Beulich
2016-02-17 10:45 ` Andrew Cooper
2016-02-17 10:58 ` Jan Beulich
2016-02-18 12:41 ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 17/30] x86/cpu: Common infrastructure for levelling context switching Andrew Cooper
2016-02-16 14:15 ` Jan Beulich
2016-02-17 8:15 ` Jan Beulich
2016-02-17 10:46 ` Andrew Cooper
2016-02-17 19:06 ` Konrad Rzeszutek Wilk
2016-02-05 13:42 ` [PATCH v2 18/30] x86/cpu: Rework AMD masking MSR setup Andrew Cooper
2016-02-17 7:40 ` Jan Beulich
2016-02-17 10:56 ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 19/30] x86/cpu: Rework Intel masking/faulting setup Andrew Cooper
2016-02-17 7:57 ` Jan Beulich
2016-02-17 10:59 ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 20/30] x86/cpu: Context switch cpuid masks and faulting state in context_switch() Andrew Cooper
2016-02-17 8:06 ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 21/30] x86/pv: Provide custom cpumasks for PV domains Andrew Cooper
2016-02-17 8:13 ` Jan Beulich
2016-02-17 11:03 ` Andrew Cooper
2016-02-17 11:14 ` Jan Beulich
2016-02-18 12:48 ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 22/30] x86/domctl: Update PV domain cpumasks when setting cpuid policy Andrew Cooper
2016-02-17 8:22 ` Jan Beulich
2016-02-17 12:13 ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 23/30] xen+tools: Export maximum host and guest cpu featuresets via SYSCTL Andrew Cooper
2016-02-05 16:12 ` Wei Liu
2016-02-17 8:30 ` Jan Beulich
2016-02-17 12:17 ` Andrew Cooper
2016-02-17 12:23 ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 24/30] tools/libxc: Modify bitmap operations to take void pointers Andrew Cooper
2016-02-05 16:12 ` Wei Liu
2016-02-08 11:40 ` Andrew Cooper
2016-02-08 16:23 ` Tim Deegan
2016-02-08 16:36 ` Ian Campbell
2016-02-10 10:07 ` Andrew Cooper
2016-02-10 10:18 ` Ian Campbell
2016-02-18 13:37 ` Andrew Cooper
2016-02-17 20:06 ` Konrad Rzeszutek Wilk
2016-02-05 13:42 ` [PATCH v2 25/30] tools/libxc: Use public/featureset.h for cpuid policy generation Andrew Cooper
2016-02-05 16:12 ` Wei Liu
2016-02-05 13:42 ` [PATCH v2 26/30] tools/libxc: Expose the automatically generated cpu featuremask information Andrew Cooper
2016-02-05 16:12 ` Wei Liu
2016-02-05 16:15 ` Wei Liu
2016-02-05 13:42 ` [PATCH v2 27/30] tools: Utility for dealing with featuresets Andrew Cooper
2016-02-05 16:13 ` Wei Liu
2016-02-05 13:42 ` [PATCH v2 28/30] tools/libxc: Wire a featureset through to cpuid policy logic Andrew Cooper
2016-02-05 16:13 ` Wei Liu
2016-02-05 13:42 ` [PATCH v2 29/30] tools/libxc: Use featuresets rather than guesswork Andrew Cooper
2016-02-05 16:13 ` Wei Liu
2016-02-17 8:55 ` Jan Beulich
2016-02-17 13:03 ` Andrew Cooper
2016-02-17 13:19 ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 30/30] tools/libxc: Calculate xstate cpuid leaf from guest information Andrew Cooper
2016-02-05 14:28 ` Jan Beulich
2016-02-05 15:22 ` Andrew Cooper
2016-02-08 17:26 ` [PATCH v2.5 31/30] Fix PV guest XSAVE handling with levelling Andrew Cooper
2016-02-17 9:02 ` Jan Beulich
2016-02-17 13:06 ` Andrew Cooper
2016-02-17 13:36 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C5F97F.7040908@citrix.com \
--to=roger.pau@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).