|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 03/21] libs/guest: introduce xc_cpu_policy_t
On Wed, Mar 31, 2021 at 09:10:13PM +0100, Andrew Cooper wrote:
> On 23/03/2021 09:58, Roger Pau Monne wrote:
> > Introduce an opaque type that is used to store the CPUID and MSRs
> > policies of a domain. Such type uses the existing cpu_policy structure
> > to store the data, but doesn't expose the type to the users of the
> > xenguest library.
> >
> > Introduce an allocation (init) and freeing function (destroy) to
> > manage the type.
> >
> > Note the type is not yet used anywhere.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > ---
> > tools/include/xenctrl.h | 6 ++++++
> > tools/libs/guest/xg_cpuid_x86.c | 28 ++++++++++++++++++++++++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
> > index e91ff92b9b1..ffb3024bfeb 100644
> > --- a/tools/include/xenctrl.h
> > +++ b/tools/include/xenctrl.h
> > @@ -2590,6 +2590,12 @@ int xc_psr_get_domain_data(xc_interface *xch,
> > uint32_t domid,
> > int xc_psr_get_hw_info(xc_interface *xch, uint32_t socket,
> > xc_psr_feat_type type, xc_psr_hw_info *hw_info);
> >
> > +typedef struct cpu_policy *xc_cpu_policy_t;
> > +
> > +/* Create and free a xc_cpu_policy object. */
> > +xc_cpu_policy_t xc_cpu_policy_init(void);
> > +void xc_cpu_policy_destroy(xc_cpu_policy_t policy);
> > +
> > int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps);
> > int xc_get_cpu_featureset(xc_interface *xch, uint32_t index,
> > uint32_t *nr_features, uint32_t *featureset);
> > diff --git a/tools/libs/guest/xg_cpuid_x86.c
> > b/tools/libs/guest/xg_cpuid_x86.c
> > index 9846f81e1f1..ade5281c178 100644
> > --- a/tools/libs/guest/xg_cpuid_x86.c
> > +++ b/tools/libs/guest/xg_cpuid_x86.c
> > @@ -659,3 +659,31 @@ out:
> >
> > return rc;
> > }
> > +
> > +xc_cpu_policy_t xc_cpu_policy_init(void)
> > +{
> > + xc_cpu_policy_t policy = calloc(1, sizeof(*policy));
> > +
> > + if ( !policy )
> > + return NULL;
> > +
> > + policy->cpuid = calloc(1, sizeof(*policy->cpuid));
> > + policy->msr = calloc(1, sizeof(*policy->msr));
> > + if ( !policy->cpuid || !policy->msr )
> > + {
> > + xc_cpu_policy_destroy(policy);
> > + return NULL;
> > + }
> > +
> > + return policy;
> > +}
> > +
> > +void xc_cpu_policy_destroy(xc_cpu_policy_t policy)
> > +{
> > + if ( !policy )
> > + return;
> > +
> > + free(policy->cpuid);
> > + free(policy->msr);
> > + free(policy);
> > +}
>
> Looking at the series as a whole, we have a fair quantity of complexity
> from short-lived dynamic allocations.
>
> I suspect that the code would be rather better if we had
>
> struct xc_cpu_policy {
> struct cpuid_policy cpuid;
> struct msr_policy msr;
> xen_cpuid_leaf_t leaves[CPUID_MAX_SERIALISED_LEAVES];
> xen_msr_entry_t msrs[MSR_MAX_SERIALISED_ENTRIES];
> /* Names perhaps subject to improvement */
> };
>
> and just made one memory allocation.
>
> This is userspace after all, and we're taking about <4k at the moment.
>
> All operations with Xen need to bounce through the leaves/msrs encoding
> (so we're using the space a minimum of twice for any logical operation
> at the higher level), and several userspace-only operations use them too.
We would still need to do some allocations for the system policies,
but yes, it would prevent some of the short-lived allocations. I
didn't care much because it's all user-space, but removing them will
likely make the code simpler.
Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |