[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v4 02/24] xen: consolidate cpuid library


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Penny, Zheng" <penny.zheng@xxxxxxx>
  • Date: Wed, 3 Dec 2025 03:58:13 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hlgJKKkJQHNlB7lz9jydKGxQANbBJMrrV0q/RBpeZw0=; b=KvWlcnY3u/bIlauCIk0tUJoGWZ7UgUrMN/m7pNDkYL26KRxzkR8dhlJrxHjx8S/U3853PSWVPOCCd4ckxZKZS/bcM7OD/iPfgFstJDD+KmWmqh2BjnyzOyTP6+3bUeiqITrXXrx+iv/2zaBl8ZhU1US7fffB9xqyN+ACWacAqcPCUtvc3ZvuVBFNkDwmwoz+aGq5Yv/2gVpGHoGuDMTVnJsnVAEz32u7OmwvCbk+mmUETU0GZRvNIgLoxXnyDJ9QmGWyiO2s5kjBAvremjYuwYrP9G0twJcHc6Ah4JMGY8U59HUx6M/xR+Fs/hBasiuZnxGxT+0T7C3zeI+o4aganQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZgcEzmpVj98v3Vuf5W6xN4gKmCEJ44FCE0+p7yVnxvulcYG8pNnowH6KtPS9k8d8w36T2F/waTcN2xhqzNi63JOhszYCuD+TfwF04zYPZzECeS3Y0vzcW8TYtJj/xudaCUOxrsk0Wwc8lkdtUUNyC5hu7fjF+lM6eUDhiHA9CIs+Wb1vGPlBKpH4Bcp59alOIBGNV+zUaP6rkNOb9bgZFvtJ1W3LtGRTnXaYnIQijb9N2Nr2d/fZ5FTp1gt4Gk9IinDFoWdJsZ+RQ4F2W1Egy585c6PKkh/+umZo9UwbjDiLcOCjOZqkkzP5KnIOEm7MwzBjS3KYz4WPHgY9JZu80A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Huang, Ray" <Ray.Huang@xxxxxxx>, "grygorii_strashko@xxxxxxxx" <grygorii_strashko@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Wed, 03 Dec 2025 03:58:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Msip_labels: MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-12-03T03:57:55.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
  • Thread-index: AQHcWtXJjf66LsUGrE2uxhJqk+lJcbUC9piAgAlt5QCAAB1GgIAC0yUQ
  • Thread-topic: [PATCH v4 02/24] xen: consolidate cpuid library

[Public]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Monday, December 1, 2025 4:23 PM
> To: Penny, Zheng <penny.zheng@xxxxxxx>
> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; grygorii_strashko@xxxxxxxx; Roger
> Pau Monné <roger.pau@xxxxxxxxxx>; Anthony PERARD
> <anthony.perard@xxxxxxxxxx>; Juergen Gross <jgross@xxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> 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 <jbeulich@xxxxxxxx>
> >> Sent: Tuesday, November 25, 2025 2:39 PM
> >> To: Penny, Zheng <penny.zheng@xxxxxxx>; Andrew Cooper
> >> <andrew.cooper3@xxxxxxxxxx>
> >> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; grygorii_strashko@xxxxxxxx; Roger
> >> Pau Monné <roger.pau@xxxxxxxxxx>; Anthony PERARD
> >> <anthony.perard@xxxxxxxxxx>; Juergen Gross <jgross@xxxxxxxx>; xen-
> >> devel@xxxxxxxxxxxxxxxxxxxx
> >> 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 <Penny.Zheng@xxxxxxx>
> >>> ---
> >>> 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.