> From: Shradha Gupta
> Sent: Sunday, April 6, 2025 1:48 AM
> [...]
> @@ -1662,6 +1708,7 @@ void print_usage(char *argv[])
> fprintf(stderr, "Usage: %s [options]\n"
> "Options are:\n"
> " -n, --no-daemonstay in foreground, don't
> daemonize\n"
> +
On April 14, 2025 10:48:47 AM PDT, Xin Li wrote:
>On 4/12/2025 4:10 PM, H. Peter Anvin wrote:
>> Also,*in this specific case* IA32_SPEC_CTRL is architecturally
>> nonserializing, i.e. WRMSR executes as WRMSRNS anyway.
>
>While the immediate form WRMSRNS could be faster because the MSR index
>is a
The VMBus driver uses ACPI for interrupt assignment on
arm64 hence it won't function in the VTL mode where only
DeviceTree can be used.
Update the VMBus driver to discover interrupt configuration
from DT.
Signed-off-by: Roman Kisel
Reviewed-by: Michael Kelley
---
drivers/hv/vmbus_drv.c | 30 ++
The arm64 Hyper-V startup path relies on ACPI to detect
running under a Hyper-V compatible hypervisor. That
doesn't work on non-ACPI systems.
Hoist the ACPI detection logic into a separate function. Then
use the vendor-specific hypervisor service call (implemented
recently in Hyper-V) via SMCCC in
The KVM/arm64 uses SMCCC to detect hypervisor presence. That code is
private, and it follows the SMCCC specification. Other existing and
emerging hypervisor guest implementations can and should use that
standard approach as well.
Factor out a common infrastructure that the guests can use, update K
On 2025-03-31 at 8:22, Xin Li (Intel) wrote:
> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
> index e672632b1cc0..6e7a9daa03d4 100644
> --- a/arch/x86/xen/xen-asm.S
> +++ b/arch/x86/xen/xen-asm.S
> @@ -399,3 +399,37 @@ SYM_CODE_END(xen_entry_SYSCALL_compat)
> RET
> SYM_FUNC_E
On 4/12/2025 4:10 PM, H. Peter Anvin wrote:
Also,*in this specific case* IA32_SPEC_CTRL is architecturally nonserializing,
i.e. WRMSR executes as WRMSRNS anyway.
While the immediate form WRMSRNS could be faster because the MSR index
is available *much* earlier in the pipeline, right?
This patch set allows the Hyper-V code to boot on ARM64 inside a Virtual Trust
Level. These levels are a part of the Virtual Secure Mode documented in the
Top-Level Functional Specification available at
https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/vsm.
The OpenHCL parav
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.
Signed-off-by: Roma
Kconfig dependencies for arm64 guests on Hyper-V require that be
ACPI enabled, and limit VTL mode to x86/x64. To enable VTL mode
on arm64 as well, update the dependencies. Since VTL mode requires
DeviceTree instead of ACPI, don’t require arm64 guests on Hyper-V
to have ACPI unconditionally.
Signed
Various parts of the hyperv code need to know what VTL
the kernel runs at, most notably VMBus needs that to
establish communication with the host.
Initialize the Virtual Trust Level field to enable
booting in the Virtual Trust Level.
Signed-off-by: Roman Kisel
Reviewed-by: Michael Kelley
---
a
Using acpi_irq_create_hierarchy() in the cases where the code
also handles OF leads to code duplication as the ACPI subsystem
doesn't provide means to compute the IRQ domain parent whereas
the OF does.
Introduce acpi_get_gsi_dispatcher() so that the drivers relying
on both ACPI and OF may use irq_
On Mon, Apr 14, 2025 at 09:01:26PM +, Dexuan Cui wrote:
> > From: Dexuan Cui
> > Sent: Monday, April 14, 2025 1:57 PM
> > > @@ -1681,12 +1728,13 @@ int main(int argc, char *argv[])
> > > static struct option long_options[] = {
> > > [...]
> > > + {"debug-enabled", no_argument,
> From: Dexuan Cui
> Sent: Monday, April 14, 2025 1:57 PM
> > @@ -1681,12 +1728,13 @@ int main(int argc, char *argv[])
> > static struct option long_options[] = {
> > [...]
> > + {"debug-enabled", no_argument, 0, 'd' },
If we use --debug, we won't have to touch the 2 lin
14 matches
Mail list logo
