Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.12.17 at 00:44, <sstabellini@xxxxxxxxxx> wrote:
> Oleksandr would like to call set_px_pminfo from a non-hypercall context,
> meaning that there are no XEN_GUEST_HANDLE parameters. Today, struct
> xen_processor_performance contains a
> 
>   XEN_GUEST_HANDLE(xen_processor_px_t) states;
> 
> field. Instead of "faking" the XEN_GUEST_HANDLE field from Xen, I
> suggested to modify set_px_pminfo to take a different struct, one
> without any XEN_GUEST_HANDLE field. For example:
> 
>  struct xen_processor_performance_internal {
>      uint32_t flags;     /* flag for Px sub info type */
>      uint32_t platform_limit;  /* Platform limitation on freq usage */
>      struct xen_pct_register control_register;
>      struct xen_pct_register status_register;
>      uint32_t state_count;     /* total available performance states */
>      struct xen_processor_px states;   <---- this is the interesting change
>      struct xen_psd_package domain_info;
>      uint32_t shared_type;     /* coordination type of this processor */
>  };
> 
> The caller, in the x86 case is
> xen/arch/x86/platform_hypercall.c:do_platform_op, would be resposible
> for issuing the copy_from_guest.

I think we don't want yet another variant of the structure: I'd
then prefer to have a function doing the translation from struct
xen_processor_performance to struct processor_performance,
and hand the result to set_px_pminfo(). For consistency I'd then
like to ask though that the same be done for set_cx_pminfo().

Jan


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