[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240805054513.GA28829@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date: Sun, 4 Aug 2024 22:45:13 -0700
From: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
To: Wei Liu <wei.liu@...nel.org>
Cc: Roman Kisel <romank@...ux.microsoft.com>, arnd@...db.de,
bhelgaas@...gle.com, bp@...en8.de, catalin.marinas@....com,
dave.hansen@...ux.intel.com, decui@...rosoft.com,
haiyangz@...rosoft.com, hpa@...or.com, kw@...ux.com,
kys@...rosoft.com, lenb@...nel.org, lpieralisi@...nel.org,
mingo@...hat.com, rafael@...nel.org, robh@...nel.org,
tglx@...utronix.de, will@...nel.org, linux-acpi@...r.kernel.org,
linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, x86@...nel.org, apais@...rosoft.com,
benhill@...rosoft.com, ssengar@...rosoft.com,
sunilmut@...rosoft.com, vdso@...bites.dev
Subject: Re: [PATCH v3 3/7] Drivers: hv: Provide arch-neutral implementation
of get_vtl()
On Sat, Aug 03, 2024 at 01:21:52AM +0000, Wei Liu wrote:
> On Fri, Jul 26, 2024 at 03:59:06PM -0700, Roman Kisel wrote:
> > To run in the VTL mode, Hyper-V drivers have to know what
> > VTL the system boots in, and the arm64/hyperv code does not
> > have the means to compute that.
> >
> > Refactor the code to hoist the function that detects VTL,
> > make it arch-neutral to be able to employ it to get the VTL
> > on arm64. Fix the hypercall output address in `get_vtl(void)`
> > not to overlap with the hypercall input area to adhere to
> > the Hyper-V TLFS.
>
> Can you split the fix out? That potentially can be backported.
>
> >
> > Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
> > ---
> > +
> > +#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
> > +u8 __init get_vtl(void)
> > +{
> > + u64 control = HV_HYPERCALL_REP_COMP_1 | HVCALL_GET_VP_REGISTERS;
> > + struct hv_get_vp_registers_input *input;
> > + struct hv_get_vp_registers_output *output;
> > + unsigned long flags;
> > + u64 ret;
> > +
> > + local_irq_save(flags);
> > + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
> > + output = *this_cpu_ptr(hyperv_pcpu_output_arg);
>
> Hmm... I don't remember why the old code didn't use
> hyperv_pcpu_output_arg but instead reused input+OFFSET as output.
>
> Saurabh, can you comment on this?
This was done to optimize memory usage. Michael has provided more
details on this in his review of the patch today.
Powered by blists - more mailing lists