在 2024/8/6 7:38, lon...@linuxonhyperv.com 写道:
From: Long Li
After napi_complete_done() is called, another NAPI may be running on
another CPU and ring the doorbell before the current CPU does. When
combined with unnecessary rings when there is no need to ARM the CQ, this
triggers error paths in
> -Original Message-
> From: lon...@linuxonhyperv.com
> Sent: Monday, August 5, 2024 7:38 PM
> To: KY Srinivasan ; Haiyang Zhang
> ; Wei Liu ; Dexuan Cui
> ; David S. Miller ; Eric Dumazet
> ; Jakub Kicinski ; Paolo Abeni
> ; Shradha Gupta ;
> Simon Horman ; Konstantin Taranov
> ; Soura
> From: lon...@linuxonhyperv.com
> Sent: Monday, August 5, 2024 4:38 PM
> [...]
> After napi_complete_done() is called, another NAPI may be running on
> another CPU and ring the doorbell before the current CPU does. When
Can you please share more details about "another NAPI"? Is it about busy_pol
This set of patches add ACPI multiprocessor wakeup support to TDX VMs
booting with device tree instead of ACPI.
Historically, x86 platforms have booted secondary processors (APs) using
INIT followed by the start up IPI (SIPI) messages. However, TDX VMs
can't use this protocol because this protocol
In order to support the ACPI mailbox wakeup in device tree, move the MADT
wakeup code out of the acpi directory, so that both ACPI and device tree
can use it.
Signed-off-by: Yunhong Jiang
---
MAINTAINERS| 2 ++
arch/x86/kernel/Makefile | 1 +
arc
Add the binding to use the ACPI wakeup mailbox mechanism to bringup APs.
Signed-off-by: Yunhong Jiang
---
.../devicetree/bindings/x86/wakeup.yaml | 41 +++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/x86/wakeup.yaml
diff --git a/D
When a TDX guest boots with the device tree instead of ACPI, it can
reuse the ACPI multiprocessor wakeup mechanism to wake up application
processors(AP), without introducing a new mechanism from scrach.
In the ACPI spec, two structures are defined to wake up the APs: the
multiprocessor wakeup stru
Parse the wakeup mailbox in the guest_late_init. Put it to the
guest_late_init, so that it will be invoked before hyperv_init() where
the mailbox address will be checked.
Signed-off-by: Yunhong Jiang
---
arch/x86/include/asm/mshyperv.h | 3 +++
arch/x86/kernel/cpu/mshyperv.c | 2 ++
drivers/hv/
The ACPI wakeup mailbox is accessed by the OS and the firmware, both are
in the guest's context, instead of the hypervisor/VMM context. Mark the
address private explicitly.
Signed-off-by: Yunhong Jiang
---
arch/x86/hyperv/hv_vtl.c | 20 ++--
1 file changed, 18 insertions(+), 2 de
The trampoline_start64 is utilized when the BSP wakes up the APs through
ACPI wakeup mailbox mechanism. Because trampoline_start64 is currently
part of the real model startup code, the real mode memory need to be
reserved.
Signed-off-by: Yunhong Jiang
---
arch/x86/hyperv/hv_vtl.c | 20 ++
The VTL2 in a TDX guest can boot utilizing the device tree instead of
ACPI tables. When the ACPI wakeup mailbox is present in device tree,
don't overwrite wakeup_secondary_cpu_64 so that the acpi_wakeup_cpu will
be used to bring up the APs.
Signed-off-by: Yunhong Jiang
---
arch/x86/hyperv/hv_vtl
On Tue, 06 Aug 2024 15:12:32 -0700, Yunhong Jiang wrote:
> Add the binding to use the ACPI wakeup mailbox mechanism to bringup APs.
>
> Signed-off-by: Yunhong Jiang
> ---
> .../devicetree/bindings/x86/wakeup.yaml | 41 +++
> 1 file changed, 41 insertions(+)
> create mode
On 07/08/2024 00:12, Yunhong Jiang wrote:
> Add the binding to use the ACPI wakeup mailbox mechanism to bringup APs.
We do not have bindings for ACPI. I think in the past it was mentioned
pretty clear - we do not care what ACPI has in the wild.
>
> Signed-off-by: Yunhong Jiang
> ---
> .../devi
13 matches
Mail list logo
