[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct xen_processor_performance"
[Public] Hi > -----Original Message----- > From: Jan Beulich <jbeulich@xxxxxxxx> > Sent: Monday, May 12, 2025 11:43 PM > To: Penny, Zheng <penny.zheng@xxxxxxx> > Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Andrew Cooper > <andrew.cooper3@xxxxxxxxxx>; Anthony PERARD <anthony.perard@xxxxxxxxxx>; > Orzel, Michal <Michal.Orzel@xxxxxxx>; Julien Grall <julien@xxxxxxx>; Roger Pau > Monné <roger.pau@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; > xen- > devel@xxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct > xen_processor_performance" > > On 06.05.2025 07:56, Penny, Zheng wrote: > > [Public] > > > > Hi, > > > >> -----Original Message----- > >> From: Jan Beulich <jbeulich@xxxxxxxx> > >> Sent: Monday, April 28, 2025 11:32 PM > >> To: Penny, Zheng <penny.zheng@xxxxxxx> > >> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Andrew Cooper > >> <andrew.cooper3@xxxxxxxxxx>; Anthony PERARD > >> <anthony.perard@xxxxxxxxxx>; Orzel, Michal <Michal.Orzel@xxxxxxx>; > >> Julien Grall <julien@xxxxxxx>; Roger Pau Monné > >> <roger.pau@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; > >> xen-devel@xxxxxxxxxxxxxxxxxxxx > >> Subject: Re: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from > >> "struct xen_processor_performance" > >> > >> On 14.04.2025 09:40, Penny Zheng wrote: > >>> --- a/xen/include/public/platform.h > >>> +++ b/xen/include/public/platform.h > >>> @@ -440,6 +440,11 @@ struct xen_psd_package { > >>> uint64_t num_processors; > >>> }; > >>> > >>> +/* Coordination type value */ > >>> +#define XEN_CPUPERF_SHARED_TYPE_HW 1 /* HW does needed > >> coordination */ > >>> +#define XEN_CPUPERF_SHARED_TYPE_ALL 2 /* All dependent CPUs > >> should > >>> +set freq */ #define XEN_CPUPERF_SHARED_TYPE_ANY 3 /* Freq can be > >> set > >>> +from any dependent CPU */ > >>> + > >>> struct xen_processor_performance { > >>> uint32_t flags; /* flag for Px sub info type */ > >>> uint32_t platform_limit; /* Platform limitation on freq usage > >>> */ @@ -449,10 +454,7 @@ struct xen_processor_performance { > >>> XEN_GUEST_HANDLE(xen_processor_px_t) states; > >>> struct xen_psd_package domain_info; > >>> /* Coordination type of this processor */ > >>> -#define XEN_CPUPERF_SHARED_TYPE_HW 1 /* HW does needed > >> coordination */ > >>> -#define XEN_CPUPERF_SHARED_TYPE_ALL 2 /* All dependent CPUs > >> should > >>> set freq */ -#define XEN_CPUPERF_SHARED_TYPE_ANY 3 /* Freq can be > >>> set > >> from any dependent CPU */ > >>> - uint32_t shared_type; > >>> + uint32_t shared_type; /* XEN_CPUPERF_SHARED_TYPE_xxx */ > >>> }; > >>> typedef struct xen_processor_performance > >>> xen_processor_performance_t; > >>> DEFINE_XEN_GUEST_HANDLE(xen_processor_performance_t); > >> > >> What's this movement about? In the public interface nothing changes? > > > > As we will have shared type in "struct xen_processor_cppc" too, maybe > > the definition would like to live at more common place, then it could be > > shared? > > Living inside "struct xen_processor_performance" looks like internal values > > for > internal field. > > If it breaks the public interface some way, I'll change it back and > > duplicate the definition in "struct xen_processor_cppc" too > > I don't think it would break anything, but I also don't see any need for the > movement. And generally we prefer to avoid unnecessary code churn. Understood, then I'll delete this change. > > Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |