[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 0/9] x86: Merge cpuid and msr policy
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 3 Apr 2023 13:47:20 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=gUTWRX+psj99xXOjpkf0l7H7LRbJFTWqro20JXGXwh0=; b=RxBA+KjG10ql6TbFMFA543YsOjZ0ETl2czMIf0S32O4TknCOZzwIvuLUXEwYvUBlVpJ1oPKafwMQgZTSiw3uuDraV+Kctpnt++svQY1gDlV+xB4onPiQ+2/W26WJtLC1FqptSBh9cQx8TC4W3n5UKZWJiHndyypLmzkfVsKvZEiNbGPKq5GH7R53uwdNY/Emtar9zVry6UzVIt8V6+TNsJANhjRdNpm/g07rwAeD4SqFGLTSuccz4NjtAPsVr7UF/jyNLQPB873hsDXXhaTb9THQGtU0+wL0orZ4UzCRi5ZyGoQ1xY/r2+1+53DpU/B1+JFwVv54yfCXqJi2TtKoCg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cv+SdaD0efSUllFyIm1fqrH2hJkDwPLoWdURfEf2rUwSlRl1jAYRBD+NoZd72egVwk9oG2loiUgyt8v0f5QQGFXob8CwcHcMqIciTEASE+eFr3TIWAbigVRIJjFcinL6WDhNCtvt7CHjUR1Kb/FOPPUmwMJvzdM6lC0TWTExOtqq9yXAuZ8A8DVJnO4ES/kczs7qEiiepREJczJOOE43Ag5Tm0XUufoqFPDCFfu1KsPmhdr1Rkch1TCSxgnX3L8VTB9Y27+MSP3wNJchg2wGXBUnQQrADYztkDzvtjNGyk3TvVBxmroJRyvCsDSIaotopoLtT2POxCz057ajBcUfog==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Mon, 03 Apr 2023 11:47:43 +0000
- Ironport-data: A9a23:hV6T8qhaHmr857Mrpjx9ZPY2X161RhEKZh0ujC45NGQN5FlHY01je htvUT3XaayCNmD8LY0kPIiy9BkE7MfUy4RkTQI5pCtkHiwb9cadCdqndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wbuOgTrWCYmYpHlUMpB4J0XpLg/Q+jpNjne+3CgaMv cKai8DEMRqu1iUc3lg8sspvkzsy+qWi0N8klgZmP6sT4AeFzyB94K83fsldEVOpGuG4IcbiL wrz5OnR1n/U+R4rFuSknt7TGqHdauePVeQmoiM+t5mK2nCulARrukoIHKN0hXNsoyeIh7hMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+ tQoLXcDcjvbtdiN0ZzqRMZ8nNoMAZn0adZ3VnFIlVk1DN4AaLWaGuDmwIEd2z09wMdTAfzZe swVLyJ1awjNaAFOPVFRD48imOCvhT/0dDgwRFC9/PJrpTSMilEuluGzYbI5efTTLSlRtlyfq W/cuXzwHzkRNcCFyCrD+XWp7gPKtXqjBNpISuXnq5aGhnWol0hQNxwvZGKliqOYi3SQRtdUL mEtr39GQa8asRbDosPGdw21pjuIswARX/JUEvYm80edx6zM+QGbC2MYCDlbZ7QOluU7WDgr3 V+hhM7yCHpkt7j9YW2Z3qeZq3W1Iyd9EIMZTSoNTA9A79y9pog210vLVow6Tv/zicDpEzbtx TzMtDI5m7gYkc8M0eO84EzDhDWv4JPOS2bZ+znqY45s1SshDKbNWmBiwQGzASpoRGpBcmS8g Q==
- Ironport-hdrordr: A9a23:qixBYqxIaI8E33WQOZ3kKrPw6L1zdoMgy1knxilNoHxuH/Bw9v re+cjzsCWftN9/Yh4dcLy7VpVoIkmsl6Kdg7NwAV7KZmCP1FdARLsI0WKI+UyCJ8SRzI9gPa cLSdkFNDXzZ2IK8PoTNmODYqodKNrsytHWuQ/HpU0dKT2D88tbnn9E4gDwKDwQeCB2QaAXOb C7/cR9qz+paR0sH7+G7ilsZZmkmzXT/qiWGCI7Ow==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, Apr 03, 2023 at 11:55:57AM +0100, Andrew Cooper wrote:
> On 30/03/2023 3:43 pm, Roger Pau Monné wrote:
> > On Thu, Mar 30, 2023 at 01:59:37PM +0100, Andrew Cooper wrote:
> >> On 30/03/2023 12:07 pm, Roger Pau Monné wrote:
> >>> On Wed, Mar 29, 2023 at 09:51:28PM +0100, Andrew Cooper wrote:
> >>>> But this does mean that we now have
> >>>>
> >>>> cpu_policy->basic.$X
> >>>> cpu_policy->feat.$Y
> >>>> cpu_policy->arch_caps.$Z
> >>> I'm not sure I like the fact that we now can't differentiate between
> >>> policy fields related to MSRs or CPUID leafs.
> >>>
> >>> Isn't there a chance we might in the future get some name space
> >>> collision by us having decided to unify both?
> >> The names are chosen by me so far, and the compiler will tell us if
> >> things actually collide.
> >>
> >> And renaming the existing field is a perfectly acceptable way of
> >> resolving a conflict which arises in the future.
> >>
> >> But yes - this was the whole point of asking the question.
> > I think I would prefer to keep the cpu_policy->{cpuid,msr}.
> > distinction if it doesn't interfere with further work.
>
> Unfortunately that's the opposite of what Jan asked for. What I have
> done, based on the prior conversation is:
>
> struct arch_domain {
> ...
>
> /*
> * The domain's CPU Policy. "cpu_policy" is considered the canonical
> * pointer, but the "cpuid" and "msr" aliases exist so the most
> * appropriate one can be used for local code clarity.
> */
> union {
> struct cpu_policy *cpu_policy;
> struct cpu_policy *cpuid;
> struct cpu_policy *msr;
> };
>
> So all the cases where you do have d->arch.cpuid.feat.$X, this continues
> to work.
>
> The cases where you pull a cpu_policy out into a local variable, there
> will be no cpuid or msr infix, but these cases already have no cpuid/msr
> part to their naming.
I see. I'm fine with this. There's still the remote possibility of
field name clash between cpuid and msr names, but we can likely sort
this out if we ever get into this position.
Thanks, Roger.
|
