[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0b3e157d-0c3f-40eb-a8a0-df4c5ae0b93a@linux.microsoft.com>
Date: Mon, 19 Feb 2024 10:36:37 +0530
From: Nuno Das Neves <nunodasneves@...ux.microsoft.com>
To: Michael Kelley <mhklinux@...look.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
"mikelley@...rosoft.com" <mikelley@...rosoft.com>,
"kys@...rosoft.com" <kys@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"decui@...rosoft.com" <decui@...rosoft.com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
"arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH] hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs
to HV_MSR_*
On 2/10/2024 2:37 AM, Michael Kelley wrote:
>
> Overall, this looks good to me. It cleans up the mess I made five
> years ago when first separating x86 from ARM64. :-(
>
> See one comment below, but otherwise,
>
> Reviewed-by: Michael Kelley <mhklinux@...look.com>
>
Thanks! Responded to your comment below.
>> #if IS_ENABLED(CONFIG_HYPERV)
>> -static inline unsigned int hv_get_nested_reg(unsigned int reg)
>> +static inline unsigned int hv_get_nested_msr(unsigned int reg)
>> {
>> - if (hv_is_sint_reg(reg))
>> - return reg - HV_REGISTER_SINT0 + HV_REGISTER_NESTED_SINT0;
>> + if (hv_is_sint_msr(reg))
>> + return reg - HV_MSR_SINT0 + HV_MSR_NESTED_SINT0;
>>
>> switch (reg) {
>> - case HV_REGISTER_SIMP:
>> - return HV_REGISTER_NESTED_SIMP;
>> - case HV_REGISTER_SIEFP:
>> - return HV_REGISTER_NESTED_SIEFP;
>> - case HV_REGISTER_SVERSION:
>> - return HV_REGISTER_NESTED_SVERSION;
>> - case HV_REGISTER_SCONTROL:
>> - return HV_REGISTER_NESTED_SCONTROL;
>> - case HV_REGISTER_EOM:
>> - return HV_REGISTER_NESTED_EOM;
>> + case HV_MSR_SIMP:
>> + return HV_MSR_NESTED_SIMP;
>> + case HV_MSR_SIEFP:
>> + return HV_MSR_NESTED_SIEFP;
>> + case HV_MSR_SVERSION:
>> + return HV_MSR_NESTED_SVERSION;
>> + case HV_MSR_SCONTROL:
>> + return HV_MSR_NESTED_SCONTROL;
>> + case HV_MSR_EOM:
>> + return HV_MSR_NESTED_EOM;
>> default:
>> return reg;
>> }
>> }
>
> This function is x86 specific, but you are using the generic HV_MSR_* flavor
> instead of the x86 specific HV_X64_MSR_* flavor like in other x86 specific code.
> Both flavors work, but I wondered if there is any reason for using the generic flavor.
>> I remember debating myself the merits of one approach vs. the other, but I
> don't think there was a solid argument either way. Given that you are
> doing the work to get this all fixed like it should have been originally, I would
> argue for being consistently one way or the other. ARM64 specific code is
> *not* using the generic HV_MSR_* flavor, so I suspect x86 code should not
> either.
>
> Michael
>
I see your point about keeping it consistent within the file.
My thinking was that hv_get_nested_msr is not inherently x86-specific, even though it
lives in arch/x86 today. However, I realize that even if this function *is* moved to
generic code in the future, at that time it could be changed to the generic prefix.
Doing so in this patch could be confusing since it introduces an inconsistency.
So, I will take your advice and keep it HV_X64_MSR_* for everything in this file.
Thanks again!
Nuno
Powered by blists - more mailing lists