On Thu, Dec 19, 2024 at 10:19:07AM -0800, Roman Kisel wrote: > > > On 12/18/2024 6:42 PM, Wei Liu wrote: > > On Wed, Dec 18, 2024 at 12:54:21PM -0800, Roman Kisel wrote: > > > The Top-Level Functional Specification for Hyper-V, Section 3.6 [1, 2], > > > disallows > > > overlapping of the input and output hypercall areas, and get_vtl(void) > > > does > > > overlap them. > > > > > > To fix this, enable allocation of the output hypercall pages when running > > > in > > > the VTL mode and use the output hypercall page of the current vCPU for the > > > hypercall. > > > > > > [1] > > > https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/hypercall-interface > > > [2] > > > https://github.com/MicrosoftDocs/Virtualization-Documentation/tree/main/tlfs > > > > > > Fixes: 8387ce06d70b ("x86/hyperv: Set Virtual Trust Level in VMBus init > > > message") > > > Signed-off-by: Roman Kisel <rom...@linux.microsoft.com> > > > --- > > > arch/x86/hyperv/hv_init.c | 2 +- > > > drivers/hv/hv_common.c | 6 +++--- > > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > > > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c > > > index c7185c6a290b..90c9ea00273e 100644 > > > --- a/arch/x86/hyperv/hv_init.c > > > +++ b/arch/x86/hyperv/hv_init.c > > > @@ -422,7 +422,7 @@ static u8 __init get_vtl(void) > > > local_irq_save(flags); > > > input = *this_cpu_ptr(hyperv_pcpu_input_arg); > > > - output = (struct hv_get_vp_registers_output *)input; > > > + output = *this_cpu_ptr(hyperv_pcpu_output_arg); > > > > You can do > > > > output = (char *)input + HV_HYP_PAGE_SIZE / 2; > > > > to avoid the extra allocation. > > > > The input and output structures surely won't take up half of the page. > Agreed on the both counts! I do think that the attempt to save here > won't help much: the hypercall output per-CPU pages in the VTL mode are > needed just as in the dom0/root partition mode because this hypercall > isn't going to be the only one required. > > In other words, we will have to allocate these pages anyway as we evolve > the code; we are trying to save here what is going to be spent anyway. Sort > of, kicking the can down the road as the saying goes :) >
If you want this patch to be backported, then the smaller the change the better. In this particular case, I don't have a strong opinion. Your original patch is small enough to be backported easily. You can keep the patch as-is. Thanks, Wei.
