[Public] > -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: Monday, December 1, 2025 4:23 PM > To: Penny, Zheng <[email protected]> > Cc: Huang, Ray <[email protected]>; [email protected]; Roger > Pau Monné <[email protected]>; Anthony PERARD > <[email protected]>; Juergen Gross <[email protected]>; xen- > [email protected]; Andrew Cooper <[email protected]> > Subject: Re: [PATCH v4 02/24] xen: consolidate cpuid library > > On 01.12.2025 07:57, Penny, Zheng wrote: > > [Public] > > > >> -----Original Message----- > >> From: Jan Beulich <[email protected]> > >> Sent: Tuesday, November 25, 2025 2:39 PM > >> To: Penny, Zheng <[email protected]>; Andrew Cooper > >> <[email protected]> > >> Cc: Huang, Ray <[email protected]>; [email protected]; Roger > >> Pau Monné <[email protected]>; Anthony PERARD > >> <[email protected]>; Juergen Gross <[email protected]>; xen- > >> [email protected] > >> Subject: Re: [PATCH v4 02/24] xen: consolidate cpuid library > >> > >> On 21.11.2025 11:57, Penny Zheng wrote: > >>> There are some cpuid library functions only referenced in > >>> XEN_DOMCTL_get{,set}_cpu_policy-case, and shall be wrapped with > >>> CONFIG_MGMT_HYPERCALLS later, otherwise they will become unreachable > >>> when MGMT_HYPERCALLS=n, and hence violate Misra 2.1 > >>> - x86_cpu_policy_clear_out_of_range_leaves > >>> - zero_leaves > >>> - x86_cpuid_copy_to_buffer > >>> - copy_leaf_to_buffer > >>> - x86_cpuid_copy_from_buffer > >>> We seperate these functions by moving other functions to a new file > >>> named cpuid-generic.c, and modify related Makefile-s to retain same > >>> behavior. > >>> > >>> Signed-off-by: Penny Zheng <[email protected]> > >>> --- > >>> v3 -> v4: > >>> - new commit > >>> --- > >>> tools/fuzz/cpu-policy/Makefile | 2 +- > >>> tools/fuzz/x86_instruction_emulator/Makefile | 10 +- > >>> tools/libs/guest/Makefile.common | 2 +- > >>> tools/tests/cpu-policy/Makefile | 2 +- > >>> tools/tests/x86_emulator/Makefile | 2 +- > >>> xen/lib/x86/Makefile | 1 + > >>> xen/lib/x86/cpuid-generic.c | 273 +++++++++++++++++++ > >>> xen/lib/x86/cpuid.c | 260 ------------------ > >>> 8 files changed, 283 insertions(+), 269 deletions(-) create mode > >>> 100644 xen/lib/x86/cpuid-generic.c > >> > >> Andrew - what's your take on such a split? Personally I'm not overly > >> happy to see related functions be scattered across two files. The > >> separation also feels pretty random, posing the risk that later some of > >> the code > may need to move back. > >> > > > > Right now, I could not think a better way to guard > x86_cpuid_copy_from{,to}_buffer with MGMT_HYPERCALLS without split, any > better suggestion? Or maybe I could add up some explanations on the file > cpuid_generic.c head note to explain the diffs between itself and cpuid.c, > something > like: > > ``` > > The difference between cpuid.c and cpuid_generic.c is that the former > > contains > library functions that has only been referenced in management hypercalls, > such as > sysctl, domctl, etc. See comment for MGMT_HYPERCALLS. > > ``` > > If one of the files is to have only MGMT_HYPERCALLS related stuff (and if, > prior to > that, using #ifdef-ary in the existing file was proven unwieldy), then imo > the more > "natural" split would be to have a separate cpuid-mgmt.c file, where then > from its > name alone it already becomes halfway clear what it to live there. > > Another option might be to properly library-fy the copy-in and copy-out > functions, > one per source file, and then referenced by lib-y (or lib-$(CONFIG_...)) from > the > Makefile. >
Thx! I'd prefer second option, we need to library-fy the copy-in, copy-out, and trim-cpuid-leaves functions. Maybe it is fragmentated, but could avoid future movement in option one > Jan
