On 04/07/18 09:51, Jan Beulich wrote:
>>>> On 04.07.18 at 10:42, <wei.l...@citrix.com> 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.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
