Re: [Xen-devel] [PATCH 06/13] libx86: Introduce a helper to serialise a cpuid_policy object

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jul 04, 2018 at 05:23:56PM +0100, Andrew Cooper wrote:
> On 04/07/18 09:51, Jan Beulich wrote:
> >>>> On 04.07.18 at 10:42, <wei.liu2@xxxxxxxxxx> wrote:
> >> On Tue, Jul 03, 2018 at 09:55:19PM +0100, Andrew Cooper wrote:
> >>> --- a/xen/include/public/arch-x86/xen.h
> >>> +++ b/xen/include/public/arch-x86/xen.h
> >>> @@ -314,6 +314,17 @@ struct xen_arch_domainconfig {
> >>>  #define XEN_ACPI_GPE0_CPUHP_BIT      2
> >>>  #endif
> >>>  
> >>> +/*
> >>> + * Representations of architectural CPUID information.  Used as the
> >>> + * serialised version of Xen's internal representation.
> >>> + */
> >>> +typedef struct xen_cpuid_leaf {
> >>> +#define XEN_CPUID_NO_SUBLEAF 0xffffffffu
> >>> +    uint32_t leaf, subleaf;
> >>> +    uint32_t a, b, c, d;
> >>> +} xen_cpuid_leaf_t;
> >>> +DEFINE_XEN_GUEST_HANDLE(xen_cpuid_leaf_t);
> >>> +
> >> Is putting this in public header while leaving
> >> CPUID_MAX_SERIALISED_LEAVES in a private header useful?
> >>
> >> How does an external user know how big a buffer it needs to provide to
> >> accommodate the return structure?
> > Yeah, this is indeed hard to tell from this patch alone. And going
> > over the titles of the remainder of the series it's also not clear
> > where a use of this structure in a domctl/sysctl would appear.
> 
> An array of (some number of) xen_cpuid_leaf_t objects is the externally
> visible representation of the policy, which is why this definition is
> externally visible.
> 
> Content of this nature will (eventually) exist in the migration stream,
> and it is also the interface by which toolstacks (libxl and Xapi) can
> make under-specified modifications to the policies.

Right. An array is needed. How can the caller of
x86_cpuid_copy_to_buffer know how big this array is? It needs to pass in
an array for the data, right?

Wei.

> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel