[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <133c9897-12a8-619a-6cf4-334bc2036755@linux.microsoft.com>
Date: Thu, 21 Aug 2025 14:15:56 -0700
From: Mukesh R <mrathor@...ux.microsoft.com>
To: Michael Kelley <mhklinux@...look.com>,
"kys@...rosoft.com" <kys@...rosoft.com>,
"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"decui@...rosoft.com" <decui@...rosoft.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"hpa@...or.com" <hpa@...or.com>,
"lpieralisi@...nel.org" <lpieralisi@...nel.org>, "kw@...ux.com"
<kw@...ux.com>,
"manivannan.sadhasivam@...aro.org" <manivannan.sadhasivam@...aro.org>,
"robh@...nel.org" <robh@...nel.org>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>, "arnd@...db.de" <arnd@...db.de>
Cc: "x86@...nel.org" <x86@...nel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v3 1/7] Drivers: hv: Introduce hv_hvcall_*() functions for
hypercall arguments
On 8/21/25 13:49, Mukesh R wrote:
> On 8/21/25 12:24, Michael Kelley wrote:
>> From: Mukesh R <mrathor@...ux.microsoft.com> Sent: Wednesday, August 20, 2025 7:58 PM
>>>
>>> On 8/20/25 17:31, Mukesh R wrote:
>>>> On 4/15/25 11:07, mhkelley58@...il.com wrote:
>>>>> From: Michael Kelley <mhklinux@...look.com>
>>>>>
>>>>>
> <snip>
>>>>
>>>>
>>>> IMHO, this is unnecessary change that just obfuscates code. With status quo
>>>> one has the advantage of seeing what exactly is going on, one can use the
>>>> args any which way, change batch size any which way, and is thus flexible.
>>
>> I started this patch set in response to some errors in open coding the
>> use of hyperv_pcpu_input/output_arg, to see if helper functions could
>> regularize the usage and reduce the likelihood of future errors. Balancing
>> the pluses and minuses of the result, in my view the helper functions are
>> an improvement, though not overwhelmingly so. Others may see the
>> tradeoffs differently, and as such I would not go to the mat in arguing the
>> patches must be taken. But if we don't take them, we need to go back and
>> clean up minor errors and inconsistencies in the open coding at some
>> existing hypercall call sites.
>
> Yes, definitely. Assuming Nuno knows what issues you are referring to,
> I'll work with him to get them addressed asap. Thanks for noticing them.
> If Nuno is not aware, I'll ping you for more info.
Talked to Nuno, he's not aware of anything pending or details. So if you
can kindly list them out here, I will make sure it gets addressed right
away.
Thanks,
-Mukesh
>>
<deleted>
>>
Powered by blists - more mailing lists