* [PATCH net] net/mlx5: report duplex full when speed is known
From: Li Tian @ 2025-09-13 6:28 UTC (permalink / raw)
To: netdev, linux-hyperv
Cc: linux-kernel, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Leon Romanovsky, linux-rdma, Haiyang Zhang
Prior commit in Fixes, duplex is always reported full as long
as the speed is known. Restore this behavior. Besides, modern
Mellanox doesn't seem to care about half duplex. This change
mitigates duplex unknown issue on Azure Mellanox 5.
Fixes: c268ca6087f55 ("net/mlx5: Expose port speed when possible")
Signed-off-by: Li Tian <litian@redhat.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index d507366d773e..9f35d3b491e0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -1118,9 +1118,11 @@ static void get_link_properties(struct net_device *netdev,
if (info) {
speed = info->speed;
lanes = info->lanes;
- duplex = DUPLEX_FULL;
} else if (data_rate_oper)
speed = 100 * data_rate_oper;
+ if (!speed)
+ goto out;
+ duplex = DUPLEX_FULL;
out:
link_ksettings->base.duplex = duplex;
--
2.50.0
^ permalink raw reply related
* Re: [PATCH v1 6/6] x86/hyperv: Enable build of hypervisor crashdump collection files
From: kernel test robot @ 2025-09-13 5:57 UTC (permalink / raw)
To: Mukesh Rathor, linux-hyperv, linux-kernel, linux-arch
Cc: oe-kbuild-all, kys, haiyangz, wei.liu, decui, tglx, mingo, bp,
dave.hansen, x86, hpa, arnd
In-Reply-To: <20250910001009.2651481-7-mrathor@linux.microsoft.com>
Hi Mukesh,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20250909]
[also build test ERROR on v6.17-rc5]
[cannot apply to tip/x86/core tip/master linus/master arnd-asm-generic/master tip/auto-latest v6.17-rc5 v6.17-rc4 v6.17-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Mukesh-Rathor/x86-hyperv-Rename-guest-crash-shutdown-function/20250910-081309
base: next-20250909
patch link: https://lore.kernel.org/r/20250910001009.2651481-7-mrathor%40linux.microsoft.com
patch subject: [PATCH v1 6/6] x86/hyperv: Enable build of hypervisor crashdump collection files
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20250913/202509131304.WGYf1Sx7-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250913/202509131304.WGYf1Sx7-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509131304.WGYf1Sx7-lkp@intel.com/
All errors (new ones prefixed by >>):
arch/x86/hyperv/hv_init.c: In function 'hyperv_init':
>> arch/x86/hyperv/hv_init.c:550:17: error: implicit declaration of function 'hv_root_crash_init' [-Wimplicit-function-declaration]
550 | hv_root_crash_init();
| ^~~~~~~~~~~~~~~~~~
vim +/hv_root_crash_init +550 arch/x86/hyperv/hv_init.c
431
432 /*
433 * This function is to be invoked early in the boot sequence after the
434 * hypervisor has been detected.
435 *
436 * 1. Setup the hypercall page.
437 * 2. Register Hyper-V specific clocksource.
438 * 3. Setup Hyper-V specific APIC entry points.
439 */
440 void __init hyperv_init(void)
441 {
442 u64 guest_id;
443 union hv_x64_msr_hypercall_contents hypercall_msr;
444 int cpuhp;
445
446 if (x86_hyper_type != X86_HYPER_MS_HYPERV)
447 return;
448
449 if (hv_common_init())
450 return;
451
452 /*
453 * The VP assist page is useless to a TDX guest: the only use we
454 * would have for it is lazy EOI, which can not be used with TDX.
455 */
456 if (hv_isolation_type_tdx())
457 hv_vp_assist_page = NULL;
458 else
459 hv_vp_assist_page = kcalloc(nr_cpu_ids,
460 sizeof(*hv_vp_assist_page),
461 GFP_KERNEL);
462 if (!hv_vp_assist_page) {
463 ms_hyperv.hints &= ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
464
465 if (!hv_isolation_type_tdx())
466 goto common_free;
467 }
468
469 if (ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
470 /* Negotiate GHCB Version. */
471 if (!hv_ghcb_negotiate_protocol())
472 hv_ghcb_terminate(SEV_TERM_SET_GEN,
473 GHCB_SEV_ES_PROT_UNSUPPORTED);
474
475 hv_ghcb_pg = alloc_percpu(union hv_ghcb *);
476 if (!hv_ghcb_pg)
477 goto free_vp_assist_page;
478 }
479
480 cpuhp = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "x86/hyperv_init:online",
481 hv_cpu_init, hv_cpu_die);
482 if (cpuhp < 0)
483 goto free_ghcb_page;
484
485 /*
486 * Setup the hypercall page and enable hypercalls.
487 * 1. Register the guest ID
488 * 2. Enable the hypercall and register the hypercall page
489 *
490 * A TDX VM with no paravisor only uses TDX GHCI rather than hv_hypercall_pg:
491 * when the hypercall input is a page, such a VM must pass a decrypted
492 * page to Hyper-V, e.g. hv_post_message() uses the per-CPU page
493 * hyperv_pcpu_input_arg, which is decrypted if no paravisor is present.
494 *
495 * A TDX VM with the paravisor uses hv_hypercall_pg for most hypercalls,
496 * which are handled by the paravisor and the VM must use an encrypted
497 * input page: in such a VM, the hyperv_pcpu_input_arg is encrypted and
498 * used in the hypercalls, e.g. see hv_mark_gpa_visibility() and
499 * hv_arch_irq_unmask(). Such a VM uses TDX GHCI for two hypercalls:
500 * 1. HVCALL_SIGNAL_EVENT: see vmbus_set_event() and _hv_do_fast_hypercall8().
501 * 2. HVCALL_POST_MESSAGE: the input page must be a decrypted page, i.e.
502 * hv_post_message() in such a VM can't use the encrypted hyperv_pcpu_input_arg;
503 * instead, hv_post_message() uses the post_msg_page, which is decrypted
504 * in such a VM and is only used in such a VM.
505 */
506 guest_id = hv_generate_guest_id(LINUX_VERSION_CODE);
507 wrmsrq(HV_X64_MSR_GUEST_OS_ID, guest_id);
508
509 /* With the paravisor, the VM must also write the ID via GHCB/GHCI */
510 hv_ivm_msr_write(HV_X64_MSR_GUEST_OS_ID, guest_id);
511
512 /* A TDX VM with no paravisor only uses TDX GHCI rather than hv_hypercall_pg */
513 if (hv_isolation_type_tdx() && !ms_hyperv.paravisor_present)
514 goto skip_hypercall_pg_init;
515
516 hv_hypercall_pg = __vmalloc_node_range(PAGE_SIZE, 1, MODULES_VADDR,
517 MODULES_END, GFP_KERNEL, PAGE_KERNEL_ROX,
518 VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
519 __builtin_return_address(0));
520 if (hv_hypercall_pg == NULL)
521 goto clean_guest_os_id;
522
523 rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
524 hypercall_msr.enable = 1;
525
526 if (hv_root_partition()) {
527 struct page *pg;
528 void *src;
529
530 /*
531 * For the root partition, the hypervisor will set up its
532 * hypercall page. The hypervisor guarantees it will not show
533 * up in the root's address space. The root can't change the
534 * location of the hypercall page.
535 *
536 * Order is important here. We must enable the hypercall page
537 * so it is populated with code, then copy the code to an
538 * executable page.
539 */
540 wrmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
541
542 pg = vmalloc_to_page(hv_hypercall_pg);
543 src = memremap(hypercall_msr.guest_physical_address << PAGE_SHIFT, PAGE_SIZE,
544 MEMREMAP_WB);
545 BUG_ON(!src);
546 memcpy_to_page(pg, 0, src, HV_HYP_PAGE_SIZE);
547 memunmap(src);
548
549 hv_remap_tsc_clocksource();
> 550 hv_root_crash_init();
551 } else {
552 hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
553 wrmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
554 }
555
556 hv_set_hypercall_pg(hv_hypercall_pg);
557
558 skip_hypercall_pg_init:
559 /*
560 * hyperv_init() is called before LAPIC is initialized: see
561 * apic_intr_mode_init() -> x86_platform.apic_post_init() and
562 * apic_bsp_setup() -> setup_local_APIC(). The direct-mode STIMER
563 * depends on LAPIC, so hv_stimer_alloc() should be called from
564 * x86_init.timers.setup_percpu_clockev.
565 */
566 old_setup_percpu_clockev = x86_init.timers.setup_percpu_clockev;
567 x86_init.timers.setup_percpu_clockev = hv_stimer_setup_percpu_clockev;
568
569 hv_apic_init();
570
571 x86_init.pci.arch_init = hv_pci_init;
572
573 register_syscore_ops(&hv_syscore_ops);
574
575 if (ms_hyperv.priv_high & HV_ACCESS_PARTITION_ID)
576 hv_get_partition_id();
577
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 6/6] x86/hyperv: Enable build of hypervisor crashdump collection files
From: kernel test robot @ 2025-09-13 4:53 UTC (permalink / raw)
To: Mukesh Rathor, linux-hyperv, linux-kernel, linux-arch
Cc: oe-kbuild-all, kys, haiyangz, wei.liu, decui, tglx, mingo, bp,
dave.hansen, x86, hpa, arnd
In-Reply-To: <20250910001009.2651481-7-mrathor@linux.microsoft.com>
Hi Mukesh,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20250909]
[also build test WARNING on v6.17-rc5]
[cannot apply to tip/x86/core tip/master linus/master arnd-asm-generic/master tip/auto-latest v6.17-rc5 v6.17-rc4 v6.17-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Mukesh-Rathor/x86-hyperv-Rename-guest-crash-shutdown-function/20250910-081309
base: next-20250909
patch link: https://lore.kernel.org/r/20250910001009.2651481-7-mrathor%40linux.microsoft.com
patch subject: [PATCH v1 6/6] x86/hyperv: Enable build of hypervisor crashdump collection files
config: x86_64-randconfig-073-20250913 (https://download.01.org/0day-ci/archive/20250913/202509131228.naboUNkE-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250913/202509131228.naboUNkE-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509131228.naboUNkE-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/mshyperv.h:272,
from arch/x86/hyperv/hv_apic.c:29:
>> include/asm-generic/mshyperv.h:370:5: warning: "CONFIG_CRASH_DUMP" is not defined, evaluates to 0 [-Wundef]
370 | #if CONFIG_CRASH_DUMP
| ^~~~~~~~~~~~~~~~~
vim +/CONFIG_CRASH_DUMP +370 include/asm-generic/mshyperv.h
369
> 370 #if CONFIG_CRASH_DUMP
371 void hv_root_crash_init(void);
372 void hv_crash_asm32(void);
373 void hv_crash_asm64_lbl(void);
374 void hv_crash_asm_end(void);
375 #else /* CONFIG_CRASH_DUMP */
376 static inline void hv_root_crash_init(void) {}
377 #endif /* CONFIG_CRASH_DUMP */
378
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 1/7] Drivers: hv: Introduce hv_hvcall_*() functions for hypercall arguments
From: Mukesh R @ 2025-09-13 2:18 UTC (permalink / raw)
To: Michael Kelley, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, lpieralisi@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, robh@kernel.org,
bhelgaas@google.com, arnd@arndb.de
Cc: x86@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arch@vger.kernel.org
In-Reply-To: <SN6PR02MB4157BF605BE8EE1777AE1860D408A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 9/12/25 08:25, Michael Kelley wrote:
> From: Michael Kelley <mhklinux@outlook.com> Sent: Monday, August 25, 2025 2:01 PM
>>
>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Friday, August 22, 2025 7:25 PM
>>>
>>> On 8/21/25 19:10, Michael Kelley wrote:
>>>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Thursday, August 21, 2025 1:50 PM
>>>>>
>>>>> On 8/21/25 12:24, Michael Kelley wrote:
>>>>>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, August 20, 2025 7:58 PM
>>>>>>>
>>>>>>> On 8/20/25 17:31, Mukesh R wrote:
>>>>>>>> With time these functions only get more complicated and error prone. The
>>>>>>>> saving of ram is very minimal, this makes analyzing crash dumps harder,
>>>>>>>> and in some cases like in your patch 3/7 disables unnecessarily in error case:
>>>>>>>>
>>>>>>>> - if (count > HV_MAX_MODIFY_GPA_REP_COUNT) {
>>>>>>>> - pr_err("Hyper-V: GPA count:%d exceeds supported:%lu\n", count,
>>>>>>>> - HV_MAX_MODIFY_GPA_REP_COUNT);
>>>>>>>> + local_irq_save(flags); <<<<<<<
>>>>>>>> ...
>>>>>>
>>>>>> FWIW, this error case is not disabled. It is checked a few lines further down as:
>>>>>
>>>>> I meant disabled interrupts. The check moves after disabling interrupts, so
>>>>> it runs "disabled" in traditional OS terminology :).
>>>>
>>>> Got it. But why is it problem to make this check with interrupts disabled?
>>>
>>> You are creating disabling overhead where that overhead previously
>>> did not exist.
>>
>> I'm not clear on what you mean by "disabling overhead". The existing code
>> does the following:
>>
>> 1) Validate that "count" is not too big, and return an error if it is.
>> 2) Disable interrupts
>> 3) Populate the per-cpu hypercall input arg
>> 4) Make the hypercall
>> 5) Re-enable interrupts
>>
>> With the patch, steps 1 and 2 are done in a different order:
>>
>> 2) Disable interrupts
>> 1) Validate that "count" is not too big. Re-enable interrupts and return an error if it is.
>> 3) Populate the per-cpu hypercall input arg
>> 4) Make the hypercall
>> 5) Re-enable interrupts
>>
>> Validating "count" with interrupts disabled is probably an additional
>> 2 or 3 instructions executed with interrupts disabled, which is negligible
>> compared to the thousands (or more) of instructions the hypercall will
>> execute with interrupts disabled.
>>
>> Or are you referring to something else as "disabling overhead"?
>
> Mukesh -- anything further on what you see as the problem here?
> I'm just not getting what your concern is.
It increases the interrupts disabled window, does a print from
interrupts disabled (not a great idea unless it is pr_emerg and system
is crashing), and in case of actual error of (count > batch_size)
interrupts are getting enabled and disabled that were not before.
> [snip]
>
>>>>>>> Furthermore, this makes us lose the ability to permanently map
>>>>>>> input/output pages in the hypervisor. So, Wei kindly undo.
>>>>>>>
>>>>>>
>>>>>> Could you elaborate on "lose the ability to permanently map
>>>>>> input/output pages in the hypervisor"? What specifically can't be
>>>>>> done and why?
>>>>>
>>>>> Input and output are mapped at fixed GPA/SPA always to avoid hyp
>>>>> having to map/unmap every time.
>>>>
>>>> OK. But how does this patch set impede doing a fixed mapping?
>>>
>>> The output address can be varied depending on the hypercall, instead
>>> of it being fixed always at fixed address:
>>>
>>> *(void **)output = space + offset; <<<<<<
>>
>> Agreed. But since mappings from GPA to SPA are page granular, having
>> such a fixed mapping means that there's a mapping for every byte in
>> the page containing the GPA to the corresponding byte in the SPA,
>> right? So even though the offset above may vary across hypercalls,
>> the output GPA still refers to the same page (since the offset is always
>> less than 4096), and that page has a fixed mapping. I would expect the
>> hypercall code in the hypervisor to look for an existing mapping based
>> on the output page, not the output address that includes the offset.
>> But I'm haven't looked at the hypervisor code. If the Hyper-V folks say
>> that a non-zero offset thwarts finding the existing mapping, what does
>> the hypervisor end up doing? Creating a 2nd mapping wouldn't seem
>> to make sense. So I'm really curious about what's going on ....
>>
>
> Again, any further information about why we "lose the ability to
> permanently map input/output pages"? It seems doubtful to me
> that an offset within the same page would make any difference,
> but maybe Hyper-V is doing something unexpected. If so, I'd like
> to know more about what that is.
>
> Michael
you've to pass the offset/pointer ever time, and hyp has to map
that instead of just per cpu permanent mapping.
-Mukesh
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 10/10] x86/hyperv/vtl: Use the wakeup mailbox to boot secondary CPUs
From: Dexuan Cui @ 2025-09-12 20:47 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-10-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
> The hypervisor is an untrusted entity for TDX guests. It cannot be used
> to boot secondary CPUs. The function hv_vtl_wakeup_secondary_cpu() cannot
> be used.
>
> Instead, the virtual firmware boots the secondary CPUs and places them in
> a state to transfer control to the kernel using the wakeup mailbox.
>
> The kernel updates the APIC callback wakeup_secondary_cpu_64() to use
> the mailbox if detected early during boot (enumerated via either an ACPI
> table or a DeviceTree node).
>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 09/10] x86/hyperv/vtl: Mark the wakeup mailbox page as private
From: Dexuan Cui @ 2025-09-12 20:47 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri, Yunhong Jiang
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-9-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
>
> From: Yunhong Jiang <yunhong.jiang@linux.intel.com>
>
> The current code maps MMIO devices as shared (decrypted) by default in a
> confidential computing VM.
>
> In a TDX environment, secondary CPUs are booted using the Multiprocessor
> Wakeup Structure defined in the ACPI specification. The virtual firmware
> and the operating system function in the guest context, without
> intervention from the VMM. Map the physical memory of the mailbox as
> private. Use the is_private_mmio() callback.
>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> Signed-off-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 08/10] x86/smpwakeup: Add a helper get the address of the wakeup mailbox
From: Dexuan Cui @ 2025-09-12 20:46 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-8-df547b1d196e@linux.intel.com>
> -----Original Message-----
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
> A Hyper-V VTL level 2 guest on a TDX environment needs to map the
> physical page of the ACPI Multiprocessor Wakeup Structure as private
> (encrypted). It needs to know the physical address of this structure.
> Add a helper function.
>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> Suggested-by: Michael Kelley <mhklinux@outlook.com>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 07/10] x86/hyperv/vtl: Setup the 64-bit trampoline for TDX guests
From: Dexuan Cui @ 2025-09-12 20:45 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri, Yunhong Jiang
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-7-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
> From: Yunhong Jiang <yunhong.jiang@linux.intel.com>
>
> The hypervisor is an untrusted entity for TDX guests. It cannot be used
> to boot secondary CPUs - neither via hypercalls not the INIT assert,
> de-assert plus Start-Up IPI messages.
>
> Instead, the platform virtual firmware boots the secondary CPUs and
> puts them in a state to transfer control to the kernel. This mechanism uses
> the wakeup mailbox described in the Multiprocessor Wakeup Structure of the
> ACPI specification. The entry point to the kernel is trampoline_start64.
>
> Allocate and setup the trampoline using the default x86_platform callbacks.
>
> The platform firmware configures the secondary CPUs in long mode. It is no
> longer necessary to locate the trampoline under 1MB memory. After handoff
> from firmware, the trampoline code switches briefly to 32-bit addressing
> mode, which has an addressing limit of 4GB. Set the upper bound of the
> trampoline memory accordingly.
>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> Signed-off-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 06/10] x86/realmode: Make the location of the trampoline configurable
From: Dexuan Cui @ 2025-09-12 20:45 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri, Yunhong Jiang, Thomas Gleixner
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-6-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
> From: Yunhong Jiang <yunhong.jiang@linux.intel.com>
>
> x86 CPUs boot in real mode. This mode uses 20-bit memory addresses (16-bit
> registers plus 4-bit segment selectors). This implies that the trampoline
> must reside under the 1MB memory boundary.
>
> There are platforms in which the firmware boots the secondary CPUs,
> switches them to long mode and transfers control to the kernel. An example
> of such mechanism is the ACPI Multiprocessor Wakeup Structure.
>
> In this scenario there is no restriction to locate the trampoline under 1MB
> memory. Moreover, certain platforms (for example, Hyper-V VTL guests) may
> not have memory available for allocation under 1MB.
>
> Add a new member to struct x86_init_resources to specify the upper bound
> for the location of the trampoline memory. Keep the default upper bound of
> 1MB to conserve the current behavior.
>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> Originally-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 05/10] x86/hyperv/vtl: Set real_mode_header in hv_vtl_init_platform()
From: Dexuan Cui @ 2025-09-12 20:43 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri, Yunhong Jiang, Thomas Gleixner
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-5-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
>[...]
> From: Yunhong Jiang <yunhong.jiang@linux.intel.com>
>
> Hyper-V VTL clears x86_platform.realmode_{init(), reserve()} in
> hv_vtl_platform_init() whereas it sets real_mode_header later in
s/hv_vtl_platform_init/hv_vtl_init_platform/
otherwise LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 04/10] x86/dt: Parse the Wakeup Mailbox for Intel processors
From: Dexuan Cui @ 2025-09-12 20:41 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri, Yunhong Jiang
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-4-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
> The Wakeup Mailbox is a mechanism to boot secondary CPUs used on systems
> that do not want or cannot use the INIT + StartUp IPI messages.
>
> The platform firmware is expected to implement the mailbox as described in
> the Multiprocessor Wakeup Structure of the ACPI specification. It is also
> expected to publish the mailbox to the operating system as described in the
> corresponding DeviceTree schema that accompanies the documentation of the
> Linux kernel.
>
> Reuse the existing functionality to set the memory location of the mailbox
> and update the wakeup_secondary_cpu_64() APIC callback. Make this
> functionality available to DeviceTree-based systems by making CONFIG_X86_
> MAILBOX_WAKEUP depend on either CONFIG_OF or
> CONFIG_ACPI_MADT_WAKEUP.
>
> do_boot_cpu() uses wakeup_secondary_cpu_64() when set. If a wakeup
> mailbox
> is found (enumerated via an ACPI table or a DeviceTree node) it will be
> used unconditionally. For cases in which this behavior is not desired, this
> APIC callback can be updated later during boot using platform-specific
> hooks.
>
> Co-developed-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 03/10] dt-bindings: reserved-memory: Wakeup Mailbox for Intel processors
From: Dexuan Cui @ 2025-09-12 20:39 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri, Yunhong Jiang
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-3-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
> Add DeviceTree bindings to enumerate the wakeup mailbox used in platform
> firmware for Intel processors.
>
> x86 platforms commonly boot secondary CPUs using an INIT assert, de-assert
> followed by Start-Up IPI messages. The wakeup mailbox can be used when this
> mechanism is unavailable.
>
> The wakeup mailbox offers more control to the operating system to boot
> secondary CPUs than a spin-table. It allows the reuse of same wakeup vector
> for all CPUs while maintaining control over which CPUs to boot and when.
> While it is possible to achieve the same level of control using a spin-
> table, it would require to specify a separate `cpu-release-addr` for each
> secondary CPU.
>
> The operation and structure of the mailbox is described in the
> Multiprocessor Wakeup Structure defined in the ACPI specification. Note
> that this structure does not specify how to publish the mailbox to the
> operating system (ACPI-based platform firmware uses a separate table). No
> ACPI table is needed in DeviceTree-based firmware to enumerate the mailbox.
>
> Add a `compatible` property that the operating system can use to discover
> the mailbox. Nodes wanting to refer to the reserved memory usually define a
> `memory-region` property. /cpus/cpu* nodes would want to refer to the
> mailbox, but they do not have such property defined in the DeviceTree
> specification. Moreover, it would imply that there is a memory region per
> CPU.
>
> Co-developed-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Mukesh R @ 2025-09-12 18:10 UTC (permalink / raw)
To: Greg KH
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, deller, arnd, sgarzare, horms
In-Reply-To: <2025091253-overwrite-carol-b197@gregkh>
On 9/12/25 04:43, Greg KH wrote:
> On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote:
>> On 9/6/25 04:36, Greg KH wrote:
>>> On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
>>>> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
>>>> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
>>>> hypervisor support, such as hypercalls, clocks/timers, Confidential
>>>> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
>>>> devices.
>>>
>>> But why are you making it so that this can not be a module anymore? You
>>> are now forcing ALL Linux distro users to always have this code in their
>>> system, despite not ever using the feature. That feels like a waste to
>>> me.
>>>
>>> What is preventing this from staying as a module? Why must you always
>>> have this code loaded at all times for everyone?
>>
>> This is currently not a module. I assume it was at the beginning. In
>> drivers/Makefile today:
>>
>> obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
>>
>>
>> More context: CONFIG_HYPERV doesn't really reflect one module. It is
>> both for kernel built in code and building of stuff in drivers/hv.
>>
>> drivers/hv then builds 4 modules:
>>
>> obj-$(CONFIG_HYPERV) += hv_vmbus.o
>> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
>> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
>> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
>>
>> Notice vmbus is using CONFIG_HYPERV because there is no
>> CONFIG_HYPERV_VMBUS. We are trying to fix that here.
>
> This series does not apply to my tree:
>
> checking file drivers/gpu/drm/Kconfig
> checking file drivers/hid/Kconfig
> checking file drivers/hv/Kconfig
> Hunk #2 FAILED at 82.
> 1 out of 2 hunks FAILED
> checking file drivers/hv/Makefile
> checking file drivers/input/serio/Kconfig
> checking file drivers/net/hyperv/Kconfig
> checking file drivers/pci/Kconfig
> checking file drivers/scsi/Kconfig
> checking file drivers/uio/Kconfig
> checking file drivers/video/fbdev/Kconfig
> checking file include/asm-generic/mshyperv.h
> Hunk #1 succeeded at 162 with fuzz 2 (offset -3 lines).
> Hunk #2 succeeded at 198 (offset -3 lines).
> Hunk #3 succeeded at 215 (offset -3 lines).
> checking file net/vmw_vsock/Kconfig
>
> What was it made against?
>
Sorry to hear that. It was built against hyper-next, but perhaps I
accidentally used our internal mirror. Let me rebase and send V2
right away.
Thanks,
-Mukesh
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH net-next] net: mana: Reduce waiting time if HWC not responding
From: Haiyang Zhang @ 2025-09-12 17:48 UTC (permalink / raw)
To: Simon Horman, Haiyang Zhang
Cc: linux-hyperv@vger.kernel.org, netdev@vger.kernel.org, Dexuan Cui,
KY Srinivasan, wei.liu@kernel.org, edumazet@google.com,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, Long Li,
ssengar@linux.microsoft.com, ernis@linux.microsoft.com,
dipayanroy@linux.microsoft.com, Konstantin Taranov, Shiraz Saleem,
andrew+netdev@lunn.ch, linux-kernel@vger.kernel.org
In-Reply-To: <20250912122849.GA30363@horms.kernel.org>
> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Friday, September 12, 2025 8:29 AM
> To: Haiyang Zhang <haiyangz@linux.microsoft.com>
> Cc: linux-hyperv@vger.kernel.org; netdev@vger.kernel.org; Haiyang Zhang
> <haiyangz@microsoft.com>; Dexuan Cui <decui@microsoft.com>; KY Srinivasan
> <kys@microsoft.com>; wei.liu@kernel.org; edumazet@google.com;
> davem@davemloft.net; kuba@kernel.org; pabeni@redhat.com; Long Li
> <longli@microsoft.com>; ssengar@linux.microsoft.com;
> ernis@linux.microsoft.com; dipayanroy@linux.microsoft.com; Konstantin
> Taranov <kotaranov@microsoft.com>; Shiraz Saleem
> <shirazsaleem@microsoft.com>; andrew+netdev@lunn.ch; linux-
> kernel@vger.kernel.org
> Subject: [EXTERNAL] Re: [PATCH net-next] net: mana: Reduce waiting time if
> HWC not responding
>
> On Wed, Sep 10, 2025 at 01:57:21PM -0700, Haiyang Zhang wrote:
> > From: Haiyang Zhang <haiyangz@microsoft.com>
> >
> > If HW Channel (HWC) is not responding, reduce the waiting time, so
> further
> > steps will fail quickly.
> > This will prevent getting stuck for a long time (30 minutes or more),
> for
> > example, during unloading while HWC is not responding.
> >
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> > drivers/net/ethernet/microsoft/mana/hw_channel.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c
> b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> > index ef072e24c46d..ada6c78a2bef 100644
> > --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c
> > +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> > @@ -881,7 +881,12 @@ int mana_hwc_send_request(struct hw_channel_context
> *hwc, u32 req_len,
> > if (!wait_for_completion_timeout(&ctx->comp_event,
> > (msecs_to_jiffies(hwc->hwc_timeout)))) {
> > if (hwc->hwc_timeout != 0)
> > - dev_err(hwc->dev, "HWC: Request timed out!\n");
> > + dev_err(hwc->dev, "HWC: Request timed out: %u ms\n",
> > + hwc->hwc_timeout);
> > +
> > + /* Reduce further waiting if HWC no response */
> > + if (hwc->hwc_timeout > 1)
> > + hwc->hwc_timeout = 1;
>
> Hi,
>
> Perhaps it is already the case, but I'm wondering if the configured
> value of hwc_timeout should be restored at some point.
Yes it's already the case: when the driver does reset/recovery, or gets
a timeout-value-message from the NIC, the time out value will be updated.
Thanks,
- Haiyang
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 02/10] x86/acpi: Move acpi_wakeup_cpu() and helpers to smpwakeup.c
From: Dexuan Cui @ 2025-09-12 16:49 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri, Yunhong Jiang
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-2-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
> The bootstrap processor uses acpi_wakeup_cpu() to indicate to firmware that
> it wants to boot a secondary CPU using a mailbox as described in the
> Multiprocessor Wakeup Structure of the ACPI specification.
>
> The platform firmware may implement the mailbox as described in the ACPI
> specification but enumerate it using a DeviceTree graph. An example of
> this is OpenHCL paravisor.
>
> Move the code used to setup and use the mailbox for CPU wakeup out of the
> ACPI directory into a new smpwakeup.c file that both ACPI and DeviceTree
> can use.
>
> No functional changes are intended.
>
> Co-developed-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v5 01/10] x86/acpi: Add a helper functions to setup and access the wakeup mailbox
From: Dexuan Cui @ 2025-09-12 16:43 UTC (permalink / raw)
To: Ricardo Neri, x86@kernel.org, Krzysztof Kozlowski, Conor Dooley,
Rob Herring, KY Srinivasan, Haiyang Zhang, Wei Liu,
Michael Kelley, Rafael J. Wysocki
Cc: ssengar@linux.microsoft.com, Chris Oo, Kirill A. Shutemov,
linux-hyperv@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Neri
In-Reply-To: <20250627-rneri-wakeup-mailbox-v5-1-df547b1d196e@linux.intel.com>
> From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Sent: Friday, June 27, 2025 8:35 PM
> [...]
> In preparation to move the functionality to wake secondary CPUs up out of
> the ACPI code, add two helper functions.
>
> The function acpi_setup_mp_wakeup_mailbox() stores the physical address of
> the mailbox and updates the wakeup_secondary_cpu_64() APIC callback.
>
> There is a slight change in behavior: now the APIC callback is updated
> before configuring CPU hotplug offline behavior. This is fine as the APIC
> callback continues to be updated unconditionally, regardless of the
> restriction on CPU offlining.
>
> The function acpi_madt_multiproc_wakeup_mailbox() returns a pointer to the
> mailbox. Use this helper function only in the portions of the code for
> which the variable acpi_mp_wake_mailbox will be out of scope once it is
> relocated out of the ACPI directory.
>
> The wakeup mailbox is only supported for CONFIG_X86_64 and needed only
> with
> CONFIG_SMP=y.
>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
LGTM
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* RE: [PATCH v3 1/7] Drivers: hv: Introduce hv_hvcall_*() functions for hypercall arguments
From: Michael Kelley @ 2025-09-12 15:25 UTC (permalink / raw)
To: Michael Kelley, Mukesh R, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com, lpieralisi@kernel.org,
kw@linux.com, manivannan.sadhasivam@linaro.org, robh@kernel.org,
bhelgaas@google.com, arnd@arndb.de
Cc: x86@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arch@vger.kernel.org
In-Reply-To: <SN6PR02MB41575CDB3874DB0867FF9E8FD43EA@SN6PR02MB4157.namprd02.prod.outlook.com>
From: Michael Kelley <mhklinux@outlook.com> Sent: Monday, August 25, 2025 2:01 PM
>
> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Friday, August 22, 2025 7:25 PM
> >
> > On 8/21/25 19:10, Michael Kelley wrote:
> > > From: Mukesh R <mrathor@linux.microsoft.com> Sent: Thursday, August 21, 2025 1:50 PM
> > >>
> > >> On 8/21/25 12:24, Michael Kelley wrote:
> > >>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, August 20, 2025 7:58 PM
> > >>>>
> > >>>> On 8/20/25 17:31, Mukesh R wrote:
> > >>>>> With time these functions only get more complicated and error prone. The
> > >>>>> saving of ram is very minimal, this makes analyzing crash dumps harder,
> > >>>>> and in some cases like in your patch 3/7 disables unnecessarily in error case:
> > >>>>>
> > >>>>> - if (count > HV_MAX_MODIFY_GPA_REP_COUNT) {
> > >>>>> - pr_err("Hyper-V: GPA count:%d exceeds supported:%lu\n", count,
> > >>>>> - HV_MAX_MODIFY_GPA_REP_COUNT);
> > >>>>> + local_irq_save(flags); <<<<<<<
> > >>>>> ...
> > >>>
> > >>> FWIW, this error case is not disabled. It is checked a few lines further down as:
> > >>
> > >> I meant disabled interrupts. The check moves after disabling interrupts, so
> > >> it runs "disabled" in traditional OS terminology :).
> > >
> > > Got it. But why is it problem to make this check with interrupts disabled?
> >
> > You are creating disabling overhead where that overhead previously
> > did not exist.
>
> I'm not clear on what you mean by "disabling overhead". The existing code
> does the following:
>
> 1) Validate that "count" is not too big, and return an error if it is.
> 2) Disable interrupts
> 3) Populate the per-cpu hypercall input arg
> 4) Make the hypercall
> 5) Re-enable interrupts
>
> With the patch, steps 1 and 2 are done in a different order:
>
> 2) Disable interrupts
> 1) Validate that "count" is not too big. Re-enable interrupts and return an error if it is.
> 3) Populate the per-cpu hypercall input arg
> 4) Make the hypercall
> 5) Re-enable interrupts
>
> Validating "count" with interrupts disabled is probably an additional
> 2 or 3 instructions executed with interrupts disabled, which is negligible
> compared to the thousands (or more) of instructions the hypercall will
> execute with interrupts disabled.
>
> Or are you referring to something else as "disabling overhead"?
Mukesh -- anything further on what you see as the problem here?
I'm just not getting what your concern is.
[snip]
> > >>>> Furthermore, this makes us lose the ability to permanently map
> > >>>> input/output pages in the hypervisor. So, Wei kindly undo.
> > >>>>
> > >>>
> > >>> Could you elaborate on "lose the ability to permanently map
> > >>> input/output pages in the hypervisor"? What specifically can't be
> > >>> done and why?
> > >>
> > >> Input and output are mapped at fixed GPA/SPA always to avoid hyp
> > >> having to map/unmap every time.
> > >
> > > OK. But how does this patch set impede doing a fixed mapping?
> >
> > The output address can be varied depending on the hypercall, instead
> > of it being fixed always at fixed address:
> >
> > *(void **)output = space + offset; <<<<<<
>
> Agreed. But since mappings from GPA to SPA are page granular, having
> such a fixed mapping means that there's a mapping for every byte in
> the page containing the GPA to the corresponding byte in the SPA,
> right? So even though the offset above may vary across hypercalls,
> the output GPA still refers to the same page (since the offset is always
> less than 4096), and that page has a fixed mapping. I would expect the
> hypercall code in the hypervisor to look for an existing mapping based
> on the output page, not the output address that includes the offset.
> But I'm haven't looked at the hypervisor code. If the Hyper-V folks say
> that a non-zero offset thwarts finding the existing mapping, what does
> the hypervisor end up doing? Creating a 2nd mapping wouldn't seem
> to make sense. So I'm really curious about what's going on ....
>
Again, any further information about why we "lose the ability to
permanently map input/output pages"? It seems doubtful to me
that an offset within the same page would make any difference,
but maybe Hyper-V is doing something unexpected. If so, I'd like
to know more about what that is.
Michael
^ permalink raw reply
* Re: [PATCH v5 4/7] KVM: SVM: Software reserved fields
From: Tom Lendacky @ 2025-09-12 13:09 UTC (permalink / raw)
To: Yosry Ahmed, Vineeth Pillai
Cc: Lan Tianyu, Michael Kelley, Paolo Bonzini, Sean Christopherson,
Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, Wei Liu,
Stephen Hemminger, Haiyang Zhang, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, K. Y. Srinivasan, x86, kvm,
linux-kernel, linux-hyperv, Venkatesh Srinivas
In-Reply-To: <67feoyvmmf2sl34kikk3btrfcedafax2pazht5tplxyeb5rtv7@eakih2vxt2xc>
On 9/11/25 17:35, Yosry Ahmed wrote:
> On Thu, Jun 03, 2021 at 03:14:37PM +0000, Vineeth Pillai wrote:
>
> Apologies for reviving this 2021 thread, but it seems like the APM says
> in Table C-1. SVM Intercept Codes that the host reserved value is
> F000_000h.
>
> APM typo or wrong KVM definition?
APM typo.
^ permalink raw reply
* Re: [PATCH net-next] net: mana: Reduce waiting time if HWC not responding
From: Simon Horman @ 2025-09-12 12:28 UTC (permalink / raw)
To: Haiyang Zhang
Cc: linux-hyperv, netdev, haiyangz, decui, kys, wei.liu, edumazet,
davem, kuba, pabeni, longli, ssengar, ernis, dipayanroy,
kotaranov, shirazsaleem, andrew+netdev, linux-kernel
In-Reply-To: <1757537841-5063-1-git-send-email-haiyangz@linux.microsoft.com>
On Wed, Sep 10, 2025 at 01:57:21PM -0700, Haiyang Zhang wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> If HW Channel (HWC) is not responding, reduce the waiting time, so further
> steps will fail quickly.
> This will prevent getting stuck for a long time (30 minutes or more), for
> example, during unloading while HWC is not responding.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> drivers/net/ethernet/microsoft/mana/hw_channel.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> index ef072e24c46d..ada6c78a2bef 100644
> --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c
> +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> @@ -881,7 +881,12 @@ int mana_hwc_send_request(struct hw_channel_context *hwc, u32 req_len,
> if (!wait_for_completion_timeout(&ctx->comp_event,
> (msecs_to_jiffies(hwc->hwc_timeout)))) {
> if (hwc->hwc_timeout != 0)
> - dev_err(hwc->dev, "HWC: Request timed out!\n");
> + dev_err(hwc->dev, "HWC: Request timed out: %u ms\n",
> + hwc->hwc_timeout);
> +
> + /* Reduce further waiting if HWC no response */
> + if (hwc->hwc_timeout > 1)
> + hwc->hwc_timeout = 1;
Hi,
Perhaps it is already the case, but I'm wondering if the configured
value of hwc_timeout should be restored at some point.
>
> err = -ETIMEDOUT;
> goto out;
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Greg KH @ 2025-09-12 11:43 UTC (permalink / raw)
To: Mukesh R
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, deller, arnd, sgarzare, horms
In-Reply-To: <d7d7b23f-eaea-2dbc-9c9d-4bee082f6fe7@linux.microsoft.com>
On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote:
> On 9/6/25 04:36, Greg KH wrote:
> > On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
> >> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
> >> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
> >> hypervisor support, such as hypercalls, clocks/timers, Confidential
> >> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
> >> devices.
> >
> > But why are you making it so that this can not be a module anymore? You
> > are now forcing ALL Linux distro users to always have this code in their
> > system, despite not ever using the feature. That feels like a waste to
> > me.
> >
> > What is preventing this from staying as a module? Why must you always
> > have this code loaded at all times for everyone?
>
> This is currently not a module. I assume it was at the beginning. In
> drivers/Makefile today:
>
> obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
>
>
> More context: CONFIG_HYPERV doesn't really reflect one module. It is
> both for kernel built in code and building of stuff in drivers/hv.
>
> drivers/hv then builds 4 modules:
>
> obj-$(CONFIG_HYPERV) += hv_vmbus.o
> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
>
> Notice vmbus is using CONFIG_HYPERV because there is no
> CONFIG_HYPERV_VMBUS. We are trying to fix that here.
This series does not apply to my tree:
checking file drivers/gpu/drm/Kconfig
checking file drivers/hid/Kconfig
checking file drivers/hv/Kconfig
Hunk #2 FAILED at 82.
1 out of 2 hunks FAILED
checking file drivers/hv/Makefile
checking file drivers/input/serio/Kconfig
checking file drivers/net/hyperv/Kconfig
checking file drivers/pci/Kconfig
checking file drivers/scsi/Kconfig
checking file drivers/uio/Kconfig
checking file drivers/video/fbdev/Kconfig
checking file include/asm-generic/mshyperv.h
Hunk #1 succeeded at 162 with fuzz 2 (offset -3 lines).
Hunk #2 succeeded at 198 (offset -3 lines).
Hunk #3 succeeded at 215 (offset -3 lines).
checking file net/vmw_vsock/Kconfig
What was it made against?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net v2] net/mlx5: Not returning mlx5_link_info table when speed is unknown
From: patchwork-bot+netdevbpf @ 2025-09-12 1:40 UTC (permalink / raw)
To: Li Tian
Cc: netdev, linux-hyperv, saeedm, tariqt, mbloch, leon, haiyangz,
bpoirier, vkuznets, cjubran, shshitrit
In-Reply-To: <20250910003732.5973-1-litian@redhat.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 10 Sep 2025 08:37:32 +0800 you wrote:
> Because mlx5e_link_info and mlx5e_ext_link_info have holes
> e.g. Azure mlx5 reports PTYS 19. Do not return it unless speed
> is retrieved successfully.
>
> Fixes: 65a5d35571849 ("net/mlx5: Refactor link speed handling with mlx5_link_info struct")
> Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Signed-off-by: Li Tian <litian@redhat.com>
>
> [...]
Here is the summary with links:
- [net,v2] net/mlx5: Not returning mlx5_link_info table when speed is unknown
https://git.kernel.org/netdev/net/c/5577352b5583
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v5 4/7] KVM: SVM: Software reserved fields
From: Yosry Ahmed @ 2025-09-11 22:35 UTC (permalink / raw)
To: Vineeth Pillai
Cc: Lan Tianyu, Michael Kelley, Paolo Bonzini, Sean Christopherson,
Vitaly Kuznetsov, Tom Lendacky, Wanpeng Li, Jim Mattson,
Joerg Roedel, Wei Liu, Stephen Hemminger, Haiyang Zhang,
H. Peter Anvin, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
K. Y. Srinivasan, x86, kvm, linux-kernel, linux-hyperv,
Venkatesh Srinivas
In-Reply-To: <a1f17a43a8e9e751a1a9cc0281649d71bdbf721b.1622730232.git.viremana@linux.microsoft.com>
On Thu, Jun 03, 2021 at 03:14:37PM +0000, Vineeth Pillai wrote:
> SVM added support for certain reserved fields to be used by
> software or hypervisor. Add the following reserved fields:
> - VMCB offset 0x3e0 - 0x3ff
> - Clean bit 31
> - SVM intercept exit code 0xf0000000
>
> Later patches will make use of this for supporting Hyper-V
> nested virtualization enhancements.
>
> Signed-off-by: Vineeth Pillai <viremana@linux.microsoft.com>
> ---
> arch/x86/include/asm/svm.h | 9 +++++++--
> arch/x86/include/uapi/asm/svm.h | 3 +++
> arch/x86/kvm/svm/svm.h | 17 +++++++++++++++--
> 3 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index 772e60efe243..e322676039f4 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -156,6 +156,12 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
> u64 avic_physical_id; /* Offset 0xf8 */
> u8 reserved_7[8];
> u64 vmsa_pa; /* Used for an SEV-ES guest */
> + u8 reserved_8[720];
> + /*
> + * Offset 0x3e0, 32 bytes reserved
> + * for use by hypervisor/software.
> + */
> + u8 reserved_sw[32];
> };
>
>
> @@ -314,7 +320,7 @@ struct ghcb {
>
>
> #define EXPECTED_VMCB_SAVE_AREA_SIZE 1032
> -#define EXPECTED_VMCB_CONTROL_AREA_SIZE 272
> +#define EXPECTED_VMCB_CONTROL_AREA_SIZE 1024
> #define EXPECTED_GHCB_SIZE PAGE_SIZE
>
> static inline void __unused_size_checks(void)
> @@ -326,7 +332,6 @@ static inline void __unused_size_checks(void)
>
> struct vmcb {
> struct vmcb_control_area control;
> - u8 reserved_control[1024 - sizeof(struct vmcb_control_area)];
> struct vmcb_save_area save;
> } __packed;
>
> diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h
> index 554f75fe013c..efa969325ede 100644
> --- a/arch/x86/include/uapi/asm/svm.h
> +++ b/arch/x86/include/uapi/asm/svm.h
> @@ -110,6 +110,9 @@
> #define SVM_VMGEXIT_GET_AP_JUMP_TABLE 1
> #define SVM_VMGEXIT_UNSUPPORTED_EVENT 0x8000ffff
>
> +/* Exit code reserved for hypervisor/software use */
> +#define SVM_EXIT_SW 0xf0000000
Apologies for reviving this 2021 thread, but it seems like the APM says
in Table C-1. SVM Intercept Codes that the host reserved value is
F000_000h.
APM typo or wrong KVM definition?
^ permalink raw reply
* Re: [PATCH v2 4/5] mshv: Allocate vp state page for HVCALL_MAP_VP_STATE_PAGE on L1VH
From: kernel test robot @ 2025-09-11 19:05 UTC (permalink / raw)
To: Nuno Das Neves, linux-hyperv, linux-kernel, prapal,
easwar.hariharan, tiala, anirudh, paekkaladevi
Cc: llvm, oe-kbuild-all, kys, haiyangz, wei.liu, decui, Jinank Jain,
Nuno Das Neves
In-Reply-To: <1757546089-2002-5-git-send-email-nunodasneves@linux.microsoft.com>
Hi Nuno,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.17-rc5 next-20250911]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nuno-Das-Neves/mshv-Only-map-vp-vp_stats_pages-if-on-root-scheduler/20250911-071732
base: linus/master
patch link: https://lore.kernel.org/r/1757546089-2002-5-git-send-email-nunodasneves%40linux.microsoft.com
patch subject: [PATCH v2 4/5] mshv: Allocate vp state page for HVCALL_MAP_VP_STATE_PAGE on L1VH
config: x86_64-randconfig-072-20250911 (https://download.01.org/0day-ci/archive/20250912/202509120214.YMomVkdP-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250912/202509120214.YMomVkdP-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509120214.YMomVkdP-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/hv/mshv_root_main.c:966:7: warning: variable 'vp' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
966 | if (ret)
| ^~~
drivers/hv/mshv_root_main.c:1030:11: note: uninitialized use occurs here
1030 | vp->vp_intercept_msg_page, input_vtl_zero);
| ^~
drivers/hv/mshv_root_main.c:966:3: note: remove the 'if' if its condition is always false
966 | if (ret)
| ^~~~~~~~
967 | goto unmap_ghcb_page;
| ~~~~~~~~~~~~~~~~~~~~
drivers/hv/mshv_root_main.c:955:7: warning: variable 'vp' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
955 | if (ret)
| ^~~
drivers/hv/mshv_root_main.c:1030:11: note: uninitialized use occurs here
1030 | vp->vp_intercept_msg_page, input_vtl_zero);
| ^~
drivers/hv/mshv_root_main.c:955:3: note: remove the 'if' if its condition is always false
955 | if (ret)
| ^~~~~~~~
956 | goto unmap_register_page;
| ~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hv/mshv_root_main.c:946:7: warning: variable 'vp' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
946 | if (ret)
| ^~~
drivers/hv/mshv_root_main.c:1030:11: note: uninitialized use occurs here
1030 | vp->vp_intercept_msg_page, input_vtl_zero);
| ^~
drivers/hv/mshv_root_main.c:946:3: note: remove the 'if' if its condition is always false
946 | if (ret)
| ^~~~~~~~
947 | goto unmap_intercept_message_page;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hv/mshv_root_main.c:917:20: note: initialize the variable 'vp' to silence this warning
917 | struct mshv_vp *vp;
| ^
| = NULL
drivers/hv/mshv_root_main.c:41:20: warning: unused function 'hv_parent_partition' [-Wunused-function]
41 | static inline bool hv_parent_partition(void)
| ^~~~~~~~~~~~~~~~~~~
4 warnings generated.
vim +966 drivers/hv/mshv_root_main.c
621191d709b1488 Nuno Das Neves 2025-03-14 911
621191d709b1488 Nuno Das Neves 2025-03-14 912 static long
621191d709b1488 Nuno Das Neves 2025-03-14 913 mshv_partition_ioctl_create_vp(struct mshv_partition *partition,
621191d709b1488 Nuno Das Neves 2025-03-14 914 void __user *arg)
621191d709b1488 Nuno Das Neves 2025-03-14 915 {
621191d709b1488 Nuno Das Neves 2025-03-14 916 struct mshv_create_vp args;
621191d709b1488 Nuno Das Neves 2025-03-14 917 struct mshv_vp *vp;
621191d709b1488 Nuno Das Neves 2025-03-14 918 struct page *intercept_message_page, *register_page, *ghcb_page;
621191d709b1488 Nuno Das Neves 2025-03-14 919 void *stats_pages[2];
621191d709b1488 Nuno Das Neves 2025-03-14 920 long ret;
621191d709b1488 Nuno Das Neves 2025-03-14 921
621191d709b1488 Nuno Das Neves 2025-03-14 922 if (copy_from_user(&args, arg, sizeof(args)))
621191d709b1488 Nuno Das Neves 2025-03-14 923 return -EFAULT;
621191d709b1488 Nuno Das Neves 2025-03-14 924
621191d709b1488 Nuno Das Neves 2025-03-14 925 if (args.vp_index >= MSHV_MAX_VPS)
621191d709b1488 Nuno Das Neves 2025-03-14 926 return -EINVAL;
621191d709b1488 Nuno Das Neves 2025-03-14 927
621191d709b1488 Nuno Das Neves 2025-03-14 928 if (partition->pt_vp_array[args.vp_index])
621191d709b1488 Nuno Das Neves 2025-03-14 929 return -EEXIST;
621191d709b1488 Nuno Das Neves 2025-03-14 930
621191d709b1488 Nuno Das Neves 2025-03-14 931 ret = hv_call_create_vp(NUMA_NO_NODE, partition->pt_id, args.vp_index,
621191d709b1488 Nuno Das Neves 2025-03-14 932 0 /* Only valid for root partition VPs */);
621191d709b1488 Nuno Das Neves 2025-03-14 933 if (ret)
621191d709b1488 Nuno Das Neves 2025-03-14 934 return ret;
621191d709b1488 Nuno Das Neves 2025-03-14 935
debba2f23756254 Jinank Jain 2025-09-10 936 ret = hv_map_vp_state_page(partition->pt_id, args.vp_index,
621191d709b1488 Nuno Das Neves 2025-03-14 937 HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
debba2f23756254 Jinank Jain 2025-09-10 938 input_vtl_zero, &intercept_message_page);
621191d709b1488 Nuno Das Neves 2025-03-14 939 if (ret)
621191d709b1488 Nuno Das Neves 2025-03-14 940 goto destroy_vp;
621191d709b1488 Nuno Das Neves 2025-03-14 941
621191d709b1488 Nuno Das Neves 2025-03-14 942 if (!mshv_partition_encrypted(partition)) {
debba2f23756254 Jinank Jain 2025-09-10 943 ret = hv_map_vp_state_page(partition->pt_id, args.vp_index,
621191d709b1488 Nuno Das Neves 2025-03-14 944 HV_VP_STATE_PAGE_REGISTERS,
debba2f23756254 Jinank Jain 2025-09-10 945 input_vtl_zero, ®ister_page);
621191d709b1488 Nuno Das Neves 2025-03-14 946 if (ret)
621191d709b1488 Nuno Das Neves 2025-03-14 947 goto unmap_intercept_message_page;
621191d709b1488 Nuno Das Neves 2025-03-14 948 }
621191d709b1488 Nuno Das Neves 2025-03-14 949
621191d709b1488 Nuno Das Neves 2025-03-14 950 if (mshv_partition_encrypted(partition) &&
621191d709b1488 Nuno Das Neves 2025-03-14 951 is_ghcb_mapping_available()) {
debba2f23756254 Jinank Jain 2025-09-10 952 ret = hv_map_vp_state_page(partition->pt_id, args.vp_index,
621191d709b1488 Nuno Das Neves 2025-03-14 953 HV_VP_STATE_PAGE_GHCB,
debba2f23756254 Jinank Jain 2025-09-10 954 input_vtl_normal, &ghcb_page);
621191d709b1488 Nuno Das Neves 2025-03-14 955 if (ret)
621191d709b1488 Nuno Das Neves 2025-03-14 956 goto unmap_register_page;
621191d709b1488 Nuno Das Neves 2025-03-14 957 }
621191d709b1488 Nuno Das Neves 2025-03-14 958
1af6cc3b10421f1 Nuno Das Neves 2025-09-10 959 /*
1af6cc3b10421f1 Nuno Das Neves 2025-09-10 960 * This mapping of the stats page is for detecting if dispatch thread
1af6cc3b10421f1 Nuno Das Neves 2025-09-10 961 * is blocked - only relevant for root scheduler
1af6cc3b10421f1 Nuno Das Neves 2025-09-10 962 */
1af6cc3b10421f1 Nuno Das Neves 2025-09-10 963 if (hv_scheduler_type == HV_SCHEDULER_TYPE_ROOT) {
621191d709b1488 Nuno Das Neves 2025-03-14 964 ret = mshv_vp_stats_map(partition->pt_id, args.vp_index,
621191d709b1488 Nuno Das Neves 2025-03-14 965 stats_pages);
621191d709b1488 Nuno Das Neves 2025-03-14 @966 if (ret)
621191d709b1488 Nuno Das Neves 2025-03-14 967 goto unmap_ghcb_page;
621191d709b1488 Nuno Das Neves 2025-03-14 968 }
621191d709b1488 Nuno Das Neves 2025-03-14 969
621191d709b1488 Nuno Das Neves 2025-03-14 970 vp = kzalloc(sizeof(*vp), GFP_KERNEL);
621191d709b1488 Nuno Das Neves 2025-03-14 971 if (!vp)
621191d709b1488 Nuno Das Neves 2025-03-14 972 goto unmap_stats_pages;
621191d709b1488 Nuno Das Neves 2025-03-14 973
621191d709b1488 Nuno Das Neves 2025-03-14 974 vp->vp_partition = mshv_partition_get(partition);
621191d709b1488 Nuno Das Neves 2025-03-14 975 if (!vp->vp_partition) {
621191d709b1488 Nuno Das Neves 2025-03-14 976 ret = -EBADF;
621191d709b1488 Nuno Das Neves 2025-03-14 977 goto free_vp;
621191d709b1488 Nuno Das Neves 2025-03-14 978 }
621191d709b1488 Nuno Das Neves 2025-03-14 979
621191d709b1488 Nuno Das Neves 2025-03-14 980 mutex_init(&vp->vp_mutex);
621191d709b1488 Nuno Das Neves 2025-03-14 981 init_waitqueue_head(&vp->run.vp_suspend_queue);
621191d709b1488 Nuno Das Neves 2025-03-14 982 atomic64_set(&vp->run.vp_signaled_count, 0);
621191d709b1488 Nuno Das Neves 2025-03-14 983
621191d709b1488 Nuno Das Neves 2025-03-14 984 vp->vp_index = args.vp_index;
621191d709b1488 Nuno Das Neves 2025-03-14 985 vp->vp_intercept_msg_page = page_to_virt(intercept_message_page);
621191d709b1488 Nuno Das Neves 2025-03-14 986 if (!mshv_partition_encrypted(partition))
621191d709b1488 Nuno Das Neves 2025-03-14 987 vp->vp_register_page = page_to_virt(register_page);
621191d709b1488 Nuno Das Neves 2025-03-14 988
621191d709b1488 Nuno Das Neves 2025-03-14 989 if (mshv_partition_encrypted(partition) && is_ghcb_mapping_available())
621191d709b1488 Nuno Das Neves 2025-03-14 990 vp->vp_ghcb_page = page_to_virt(ghcb_page);
621191d709b1488 Nuno Das Neves 2025-03-14 991
1af6cc3b10421f1 Nuno Das Neves 2025-09-10 992 if (hv_scheduler_type == HV_SCHEDULER_TYPE_ROOT)
621191d709b1488 Nuno Das Neves 2025-03-14 993 memcpy(vp->vp_stats_pages, stats_pages, sizeof(stats_pages));
621191d709b1488 Nuno Das Neves 2025-03-14 994
621191d709b1488 Nuno Das Neves 2025-03-14 995 /*
621191d709b1488 Nuno Das Neves 2025-03-14 996 * Keep anon_inode_getfd last: it installs fd in the file struct and
621191d709b1488 Nuno Das Neves 2025-03-14 997 * thus makes the state accessible in user space.
621191d709b1488 Nuno Das Neves 2025-03-14 998 */
621191d709b1488 Nuno Das Neves 2025-03-14 999 ret = anon_inode_getfd("mshv_vp", &mshv_vp_fops, vp,
621191d709b1488 Nuno Das Neves 2025-03-14 1000 O_RDWR | O_CLOEXEC);
621191d709b1488 Nuno Das Neves 2025-03-14 1001 if (ret < 0)
621191d709b1488 Nuno Das Neves 2025-03-14 1002 goto put_partition;
621191d709b1488 Nuno Das Neves 2025-03-14 1003
621191d709b1488 Nuno Das Neves 2025-03-14 1004 /* already exclusive with the partition mutex for all ioctls */
621191d709b1488 Nuno Das Neves 2025-03-14 1005 partition->pt_vp_count++;
621191d709b1488 Nuno Das Neves 2025-03-14 1006 partition->pt_vp_array[args.vp_index] = vp;
621191d709b1488 Nuno Das Neves 2025-03-14 1007
621191d709b1488 Nuno Das Neves 2025-03-14 1008 return ret;
621191d709b1488 Nuno Das Neves 2025-03-14 1009
621191d709b1488 Nuno Das Neves 2025-03-14 1010 put_partition:
621191d709b1488 Nuno Das Neves 2025-03-14 1011 mshv_partition_put(partition);
621191d709b1488 Nuno Das Neves 2025-03-14 1012 free_vp:
621191d709b1488 Nuno Das Neves 2025-03-14 1013 kfree(vp);
621191d709b1488 Nuno Das Neves 2025-03-14 1014 unmap_stats_pages:
1af6cc3b10421f1 Nuno Das Neves 2025-09-10 1015 if (hv_scheduler_type == HV_SCHEDULER_TYPE_ROOT)
621191d709b1488 Nuno Das Neves 2025-03-14 1016 mshv_vp_stats_unmap(partition->pt_id, args.vp_index);
621191d709b1488 Nuno Das Neves 2025-03-14 1017 unmap_ghcb_page:
debba2f23756254 Jinank Jain 2025-09-10 1018 if (mshv_partition_encrypted(partition) && is_ghcb_mapping_available())
debba2f23756254 Jinank Jain 2025-09-10 1019 hv_unmap_vp_state_page(partition->pt_id, args.vp_index,
debba2f23756254 Jinank Jain 2025-09-10 1020 HV_VP_STATE_PAGE_GHCB, vp->vp_ghcb_page,
621191d709b1488 Nuno Das Neves 2025-03-14 1021 input_vtl_normal);
621191d709b1488 Nuno Das Neves 2025-03-14 1022 unmap_register_page:
debba2f23756254 Jinank Jain 2025-09-10 1023 if (!mshv_partition_encrypted(partition))
debba2f23756254 Jinank Jain 2025-09-10 1024 hv_unmap_vp_state_page(partition->pt_id, args.vp_index,
621191d709b1488 Nuno Das Neves 2025-03-14 1025 HV_VP_STATE_PAGE_REGISTERS,
debba2f23756254 Jinank Jain 2025-09-10 1026 vp->vp_register_page, input_vtl_zero);
621191d709b1488 Nuno Das Neves 2025-03-14 1027 unmap_intercept_message_page:
debba2f23756254 Jinank Jain 2025-09-10 1028 hv_unmap_vp_state_page(partition->pt_id, args.vp_index,
621191d709b1488 Nuno Das Neves 2025-03-14 1029 HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
debba2f23756254 Jinank Jain 2025-09-10 1030 vp->vp_intercept_msg_page, input_vtl_zero);
621191d709b1488 Nuno Das Neves 2025-03-14 1031 destroy_vp:
621191d709b1488 Nuno Das Neves 2025-03-14 1032 hv_call_delete_vp(partition->pt_id, args.vp_index);
621191d709b1488 Nuno Das Neves 2025-03-14 1033 return ret;
621191d709b1488 Nuno Das Neves 2025-03-14 1034 }
621191d709b1488 Nuno Das Neves 2025-03-14 1035
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 5/5] mshv: Introduce new hypercall to map stats page for L1VH partitions
From: Nuno Das Neves @ 2025-09-11 18:00 UTC (permalink / raw)
To: Easwar Hariharan
Cc: linux-hyperv, linux-kernel, prapal, tiala, anirudh, paekkaladevi,
kys, haiyangz, wei.liu, decui, Jinank Jain
In-Reply-To: <949318ba-7623-42d2-90fd-0664915d994c@linux.microsoft.com>
On 9/11/2025 9:32 AM, Easwar Hariharan wrote:
> On 9/10/2025 4:14 PM, Nuno Das Neves wrote:
>> From: Jinank Jain <jinankjain@linux.microsoft.com>
>>
>> Introduce HVCALL_MAP_STATS_PAGE2 which provides a map location (GPFN)
>> to map the stats to. This hypercall is required for L1VH partitions,
>> depending on the hypervisor version. This uses the same check as the
>> state page map location; mshv_use_overlay_gpfn().
>>
>> Add mshv_map_vp_state_page() helpers to use this new hypercall or the
>> old one depending on availability.
>>
>> For unmapping, the original HVCALL_UNMAP_STATS_PAGE works for both
>> cases.
>>
>> Signed-off-by: Jinank Jain <jinankjain@linux.microsoft.com>
>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>> ---
>> drivers/hv/mshv_root.h | 10 ++--
>> drivers/hv/mshv_root_hv_call.c | 89 ++++++++++++++++++++++++++++++++--
>> drivers/hv/mshv_root_main.c | 25 ++++++----
>> include/hyperv/hvgdk_mini.h | 1 +
>> include/hyperv/hvhdk_mini.h | 7 +++
>> 5 files changed, 112 insertions(+), 20 deletions(-)
>>
> <snip>
>
>> @@ -849,10 +850,13 @@ static void mshv_vp_stats_unmap(u64 partition_id, u32 vp_index)
>> };
>>
>> identity.vp.stats_area_type = HV_STATS_AREA_SELF;
>> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
>> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
>> +
>> + if (stats_pages[HV_STATS_AREA_PARENT] == stats_pages[HV_STATS_AREA_SELF])
>> + return;
>
> Nit, without patch 2, this hunk is a no-op. Despite that, looks good to me.
>
Ah, thanks - in fact it probably should have been in that patch instead of
this one in the first place.
> Reviewed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
>
>>
>> identity.vp.stats_area_type = HV_STATS_AREA_PARENT;
>> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
>> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
>> }
>
> <snip>
^ permalink raw reply
* Re: [PATCH v2 5/5] mshv: Introduce new hypercall to map stats page for L1VH partitions
From: Easwar Hariharan @ 2025-09-11 16:32 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, prapal, tiala, anirudh, paekkaladevi,
easwar.hariharan, kys, haiyangz, wei.liu, decui, Jinank Jain
In-Reply-To: <1757546089-2002-6-git-send-email-nunodasneves@linux.microsoft.com>
On 9/10/2025 4:14 PM, Nuno Das Neves wrote:
> From: Jinank Jain <jinankjain@linux.microsoft.com>
>
> Introduce HVCALL_MAP_STATS_PAGE2 which provides a map location (GPFN)
> to map the stats to. This hypercall is required for L1VH partitions,
> depending on the hypervisor version. This uses the same check as the
> state page map location; mshv_use_overlay_gpfn().
>
> Add mshv_map_vp_state_page() helpers to use this new hypercall or the
> old one depending on availability.
>
> For unmapping, the original HVCALL_UNMAP_STATS_PAGE works for both
> cases.
>
> Signed-off-by: Jinank Jain <jinankjain@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 10 ++--
> drivers/hv/mshv_root_hv_call.c | 89 ++++++++++++++++++++++++++++++++--
> drivers/hv/mshv_root_main.c | 25 ++++++----
> include/hyperv/hvgdk_mini.h | 1 +
> include/hyperv/hvhdk_mini.h | 7 +++
> 5 files changed, 112 insertions(+), 20 deletions(-)
>
<snip>
> @@ -849,10 +850,13 @@ static void mshv_vp_stats_unmap(u64 partition_id, u32 vp_index)
> };
>
> identity.vp.stats_area_type = HV_STATS_AREA_SELF;
> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
> +
> + if (stats_pages[HV_STATS_AREA_PARENT] == stats_pages[HV_STATS_AREA_SELF])
> + return;
Nit, without patch 2, this hunk is a no-op. Despite that, looks good to me.
Reviewed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
>
> identity.vp.stats_area_type = HV_STATS_AREA_PARENT;
> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
> }
<snip>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox