Le 14/01/2026 à 14:45, Jan Beulich a écrit : > ... as far as we presently use them in the codebase. > > Signed-off-by: Jan Beulich <[email protected]> > --- > Or should we make both parts proper featureset elements? At least > APERFMPERF could likely be made visible to guests (in principle). > --- > v3: Use SDM-conforming names. (Sorry Jason, had to drop you R-b once > again.) > v2: Use bool and unions. > > --- a/xen/include/xen/lib/x86/cpu-policy.h > +++ b/xen/include/xen/lib/x86/cpu-policy.h > @@ -121,7 +121,46 @@ struct cpu_policy > uint64_t :64, :64; /* Leaf 0x3 - PSN. */ > uint64_t :64, :64; /* Leaf 0x4 - Structured Cache. */ > uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */ > - uint64_t :64, :64; /* Leaf 0x6 - Therm/Perf. */ > + > + /* Leaf 0x6 - Therm/Perf. */ > + union { > + uint32_t _6a; > + struct { > + bool :1, > + turbo_boost:1, > + arat:1, > + :1, > + :1, > + :1, > + :1, > + hwp:1, > + hwp_interrupt:1, > + hwp_activity_window:1, > + hwp_epp:1, > + hwp_request_pkg:1, > + :1, > + hdc:1, > + :1, > + :1, > + hwp_peci_override:1, > + :1, > + :1, > + hw_feedback:1; > + }; > + }; > + union { > + uint32_t _6b; > + }; > + union { > + uint32_t _6c; > + struct { > + bool hw_feedback_cap:1; > + }; > + }; > + union { > + uint32_t _6d; > + }; > +
While I'm ok for the a and c unions, I'm not convinced by the b and d ones (union with just a single uint32_t in it) as it's quite verbose and inconsistent with the rest of the cpu_policy structure. > uint64_t :64, :64; /* Leaf 0x7 - Structured Features. */ > uint64_t :64, :64; /* Leaf 0x8 - rsvd */ > uint64_t :64, :64; /* Leaf 0x9 - DCA */ > > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
