From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/8] libx86: Introduce x86_cpu_policies_are_compatible()
Date: Thu, 12 Sep 2019 08:59:55 +0100 [thread overview]
Message-ID: <170fe9e0-bdbe-94d1-cc53-cb4128b3079a@citrix.com> (raw)
In-Reply-To: <1bd690aa-bd94-48df-c9a4-c619c02fa408@suse.com>
On 12/09/2019 08:43, Jan Beulich wrote:
> On 11.09.2019 22:04, Andrew Cooper wrote:
>> This helper will eventually be the core "can a guest confiured like this run
>> on the CPU?" logic. For now, it is just enough of a stub to allow us to
>> replace the hypercall interface while retaining the previous behaviour.
>>
>> It will be expanded as various other bits of CPUID handling get cleaned up.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Fundamentally
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> but a couple of remarks:
>
> For one, despite being just testing code, I think the two test[]
> arrays could do with constification.
Sadly they can't. It is a consequence of struct cpu_policy using
non-const pointers.
I tried introducing struct const_cpu_policy but that is even worse
because it prohibits operating on the system policy objects in Xen.
Overall, dropping a const in the unit tests turned out to be the least
bad option, unless you have a radically different suggestion to try.
>
>> --- a/xen/include/xen/lib/x86/cpu-policy.h
>> +++ b/xen/include/xen/lib/x86/cpu-policy.h
>> @@ -11,6 +11,25 @@ struct cpu_policy
>> struct msr_policy *msr;
>> };
>>
>> +struct cpu_policy_errors
>> +{
>> + uint32_t leaf, subleaf;
>> + uint32_t msr;
>> +};
>> +
>> +#define INIT_CPU_POLICY_ERRORS { ~0u, ~0u, ~0u }
> Instead of this (and using it in every caller), couldn't the function
> fill this first thing? (The initializer isn't strictly needed anyway,
> as consumers are supposed to look at the structure only when having
> got back an error from the function, but since error paths fill just
> a subset of the fields I can see how pre-filling the whole structure
> is easier.)
At the moment, error pointers are conditionally written on error, which
means that all callers passing non-NULL need to initialise.
This could be altered to have xc_set_domain_cpu_policy() and
x86_cpu_policies_are_compatible() pro-actively set "no error" to begin
with, but that doesn't remove the need for INIT_CPU_POLICY_ERRORS in the
first place.
>
>> --- /dev/null
>> +++ b/xen/lib/x86/policy.c
>> @@ -0,0 +1,53 @@
>> +#include "private.h"
>> +
>> +#include <xen/lib/x86/cpu-policy.h>
>> +
>> +int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>> + const struct cpu_policy *guest,
>> + struct cpu_policy_errors *e)
>> +{
>> + uint32_t leaf = -1, subleaf = -1, msr = -1;
>> + int ret = -EINVAL;
>> +
>> +#define NA XEN_CPUID_NO_SUBLEAF
>> +#define FAIL_CPUID(l, s) do { leaf = (l); subleaf = (s); goto out; } while ( 0 )
>> +#define FAIL_MSR(m) do { msr = (m); goto out; } while ( 0 )
>> +
>> + if ( guest->cpuid->basic.max_leaf > host->cpuid->basic.max_leaf )
>> + FAIL_CPUID(0, NA);
>> +
>> + if ( guest->cpuid->extd.max_leaf > host->cpuid->extd.max_leaf )
>> + FAIL_CPUID(0x80000008, NA);
>> +
>> + /* TODO: Audit more CPUID data. */
>> +
>> + if ( ~host->msr->plaform_info.raw & guest->msr->plaform_info.raw )
> I've noticed this only here, but there are numerous instances elsewhere:
> Could I talk you into fixing the spelling mistake (missing 't' in
> "platform_info") here or in a prereq patch (feel free to add my ack there
> without even posting)?
I'd not even noticed the mistake. I'll get a fixup sorted as you suggest.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-09-12 8:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 20:04 [Xen-devel] [PATCH 0/8] x86/cpuid: Switch to using XEN_DOMCTL_set_cpumsr_policy Andrew Cooper
2019-09-11 20:04 ` [Xen-devel] [PATCH 1/8] libx86: Introduce x86_cpu_policies_are_compatible() Andrew Cooper
2019-09-12 7:43 ` Jan Beulich
2019-09-12 7:59 ` Andrew Cooper [this message]
2019-09-12 8:22 ` Jan Beulich
2019-09-12 11:41 ` Andrew Cooper
2019-09-11 20:04 ` [Xen-devel] [PATCH 2/8] x86/cpuid: Split update_domain_cpuid_info() in half Andrew Cooper
2019-09-12 7:52 ` Jan Beulich
2019-09-12 8:07 ` Andrew Cooper
2019-09-11 20:04 ` [Xen-devel] [PATCH 3/8] x86/domctl: Implement XEN_DOMCTL_set_cpumsr_policy Andrew Cooper
2019-09-12 8:06 ` Jan Beulich
2019-09-12 13:15 ` Andrew Cooper
2019-09-12 13:20 ` Jan Beulich
2019-09-12 16:34 ` Andrew Cooper
2019-09-11 20:05 ` [Xen-devel] [PATCH 4/8] tools/libxc: Pre-cleanup for xc_cpuid_{set, apply_policy}() Andrew Cooper
2019-09-12 8:09 ` Jan Beulich
2019-09-12 8:17 ` Jan Beulich
2019-09-12 8:38 ` Andrew Cooper
2019-09-11 20:05 ` [Xen-devel] [PATCH 5/8] tools/libxc: Rework xc_cpuid_set() to use {get, set}_cpu_policy() Andrew Cooper
2019-09-12 8:19 ` Jan Beulich
2019-09-12 8:36 ` Andrew Cooper
2019-09-12 9:11 ` Jan Beulich
2019-09-12 13:21 ` Andrew Cooper
2019-09-11 20:05 ` [Xen-devel] [PATCH 6/8] tools/libxc: Rework xc_cpuid_apply_policy() " Andrew Cooper
2019-09-12 9:02 ` Jan Beulich
2019-09-12 13:47 ` Andrew Cooper
2019-09-11 20:05 ` [Xen-devel] [PATCH 7/8] x86/domctl: Drop XEN_DOMCTL_set_cpuid Andrew Cooper
2019-09-12 9:04 ` Jan Beulich
2019-09-11 20:05 ` [Xen-devel] [PATCH 8/8] x86/cpuid: Enable CPUID Faulting for the control domain Andrew Cooper
2019-09-12 9:07 ` Jan Beulich
2019-09-12 9:28 ` Andrew Cooper
2019-09-12 18:55 ` [Xen-devel] [PATCH v2 8/8] x86/cpuid: Enable CPUID Faulting for the control domain by default Andrew Cooper
2019-09-13 6:38 ` Jan Beulich
2019-09-13 14:56 ` Andrew Cooper
2019-09-12 18:55 ` [Xen-devel] [PATCH v2 0.5/8] libx86: Proactively initialise error pointers Andrew Cooper
2019-09-13 6:20 ` 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=170fe9e0-bdbe-94d1-cc53-cb4128b3079a@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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).