From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 4/6] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid()
Date: Fri, 20 Jan 2017 16:02:21 +0000 [thread overview]
Message-ID: <9f11b0f9-c0e4-6cde-cf33-4ffe6360e019@citrix.com> (raw)
In-Reply-To: <588241B702000078001324B9@prv-mh.provo.novell.com>
On 20/01/17 15:58, Jan Beulich wrote:
>>>> On 18.01.17 at 20:40, <andrew.cooper3@citrix.com> wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -163,6 +163,24 @@ static void recalculate_xstate(struct cpuid_policy *p)
>> }
>> }
>>
>> +static void recalculate_common(struct cpuid_policy *p)
>> +{
>> + switch ( p->x86_vendor )
>> + {
>> + case X86_VENDOR_INTEL:
>> + p->extd.vendor_ebx = 0;
>> + p->extd.vendor_ecx = 0;
>> + p->extd.vendor_edx = 0;
>> + break;
>> +
>> + case X86_VENDOR_AMD:
>> + p->extd.vendor_ebx = p->basic.vendor_ebx;
>> + p->extd.vendor_ecx = p->basic.vendor_ecx;
>> + p->extd.vendor_edx = p->basic.vendor_edx;
>> + break;
>> + }
>> +}
> I find the word "common" in the name here not very indicative
> of what the function does, especially with ...
>
>> @@ -227,12 +245,12 @@ static void __init calculate_host_policy(void)
>> min_t(uint32_t, p->basic.max_leaf, ARRAY_SIZE(p->basic.raw) - 1);
>> p->feat.max_subleaf =
>> min_t(uint32_t, p->feat.max_subleaf, ARRAY_SIZE(p->feat.raw) - 1);
>> - p->extd.max_leaf =
>> - min_t(uint32_t, p->extd.max_leaf,
>> - 0x80000000u + ARRAY_SIZE(p->extd.raw) - 1);
>> + p->extd.max_leaf = 0x80000000 | min_t(uint32_t, p->extd.max_leaf & 0xffff,
>> + ARRAY_SIZE(p->extd.raw) - 1);
>>
>> cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
>> recalculate_xstate(p);
>> + recalculate_common(p);
>> }
> ... the neighboring call here (which is quite a bit more specific).
> Of course possible alternatives depend on what further uses of
> this function you do (or do not) plan, but by the name of the
> other function here it could be recalculate_extd_vendor().
It adjustments common to the global calculations, and the per-domain
recalculations.
It isn't however just per-vendor adjustments; there are global
adjustments (like clobbering the reserved leaves).
I am open to any naming suggestions.
>
>> @@ -901,9 +925,21 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>> return cpuid_hypervisor_leaves(v, leaf, subleaf, res);
>>
>> case 0x80000000 ... 0x80000000 + CPUID_GUEST_NR_EXTD - 1:
>> - if ( leaf > p->extd.max_leaf )
>> + ASSERT((p->extd.max_leaf & 0xffff) < ARRAY_SIZE(p->extd.raw));
>> + if ( (leaf & 0xffff) > min_t(uint32_t, p->extd.max_leaf & 0xffff,
>> + ARRAY_SIZE(p->extd.raw) - 1) )
>> return;
>> - goto legacy;
>> +
>> + switch ( leaf )
>> + {
>> + default:
>> + goto legacy;
>> +
>> + case 0x80000000:
>> + *res = p->extd.raw[leaf & 0xffff];
> I take it that the plan is to have further leaves and up here, or else
> the array index could simply be literal zero.
I believe you found your answer in the following patch? Eventually
(when the legacy path disappears), this entire switch statement will go.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-01-20 16:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 19:40 [PATCH 0/6] x86/cpuid: Handling of simple leaves in guest_cpuid() Andrew Cooper
2017-01-18 19:40 ` [PATCH 1/6] x86/cpuid: Hide VT-x/SVM from HVM-based control domains Andrew Cooper
2017-01-19 3:56 ` Doug Goldstein
2017-01-19 14:13 ` Andrew Cooper
2017-01-20 15:44 ` Jan Beulich
2017-01-24 14:38 ` Roger Pau Monné
2017-01-24 15:10 ` Jan Beulich
2017-01-24 15:41 ` Roger Pau Monné
2017-01-24 16:17 ` Andrew Cooper
2017-01-18 19:40 ` [PATCH 2/6] x86/cpuid: Remove BUG_ON() condition from guest_cpuid() Andrew Cooper
2017-01-19 3:57 ` Doug Goldstein
2017-01-20 15:45 ` Jan Beulich
2017-01-18 19:40 ` [PATCH 3/6] x86/cpuid: Handle leaf 0 in guest_cpuid() Andrew Cooper
2017-01-19 4:02 ` Doug Goldstein
2017-01-20 15:48 ` Jan Beulich
2017-01-18 19:40 ` [PATCH 4/6] x86/cpuid: Handle leaf 0x80000000 " Andrew Cooper
2017-01-19 4:03 ` Doug Goldstein
2017-01-20 15:58 ` Jan Beulich
2017-01-20 16:02 ` Andrew Cooper [this message]
2017-01-18 19:40 ` [PATCH 5/6] x86/cpuid: Handle the long vendor string " Andrew Cooper
2017-01-19 4:03 ` Doug Goldstein
2017-01-20 16:00 ` Jan Beulich
2017-01-20 16:03 ` Andrew Cooper
2017-01-18 19:40 ` [PATCH 6/6] x86/cpuid: Only recalculate the shared feature bits once Andrew Cooper
2017-01-19 4:03 ` Doug Goldstein
2017-01-19 11:01 ` Wei Liu
2017-01-20 16:06 ` 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=9f11b0f9-c0e4-6cde-cf33-4ffe6360e019@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.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).