Re: [PATCH v2] x86/amd: do not expose HWCR.TscFreqSel to guests

On 13.09.2023 16:52, Roger Pau Monne wrote: > OpenBSD 7.3 will unconditionally access HWCR if the TSC is reported as > Invariant, and it will then attempt to also unconditionally access PSTATE0 if > HWCR.TscFreqSel is set (currently the case on Xen). > > The relation between HWCR.TscFreqSel and

Re: [XEN v1 4/4] xen/arm: traps.c: Enclose VMSA specific registers within CONFIG_MMU

Hi, Ayan On 2023/9/11 21:59, Ayan Kumar Halder wrote: The VMSA specific registers (ie TCR, TTBR0, TTBR1, VTTBR, etc) are valid when MMU is used, thus we can enclose them with CONFIG_MMU. Signed-off-by: Ayan Kumar Halder --- xen/arch/arm/traps.c | 17 +++-- 1 file changed, 15

Re: (Debian) Bug#1051862: server flooded with xen_mc_flush warnings with xen 4.17 + linux 6.1

Hi Hans, On 13.09.23 23:38, Hans van Kranenburg wrote: Hi Radoslav, Thanks for your report... Hi Juergen, Boris and xen-devel, At Debian, we got the report below. (Also at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051862) This hardware, with only Xen and Dom0 running is hitting the

[PATCH v10 26/38] x86/fred: Add a NMI entry stub for FRED

From: "H. Peter Anvin (Intel)" On a FRED system, NMIs nest both with themselves and faults, transient information is saved into the stack frame, and NMI unblocking only happens when the stack frame indicates that so should happen. Thus, the NMI entry stub for FRED is really quite small...

[PATCH v10 31/38] x86/fred: Fixup fault on ERETU by jumping to fred_entrypoint_user

If the stack frame contains an invalid user context (e.g. due to invalid SS, a non-canonical RIP, etc.) the ERETU instruction will trap (#SS or #GP). >From a Linux point of view, this really should be considered a user space failure, so use the standard fault fixup mechanism to intercept the

[PATCH v10 30/38] x86/fred: Let ret_from_fork_asm() jmp to asm_fred_exit_user when FRED is enabled

From: "H. Peter Anvin (Intel)" Let ret_from_fork_asm() jmp to asm_fred_exit_user when FRED is enabled, otherwise the existing IDT code is chosen. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/entry/entry_64.S | 6 ++

[PATCH v10 28/38] x86/fred: FRED entry/exit and dispatch code

From: "H. Peter Anvin (Intel)" The code to actually handle kernel and event entry/exit using FRED. It is split up into two files thus: - entry_64_fred.S contains the actual entrypoints and exit code, and saves and restores registers. - entry_fred.c contains the two-level event dispatch code

[PATCH v10 32/38] x86/entry/calling: Allow PUSH_AND_CLEAR_REGS being used beyond actual entry code

From: "Peter Zijlstra (Intel)" PUSH_AND_CLEAR_REGS could be used besides actual entry code; in that case %rbp shouldn't be cleared (otherwise the frame pointer is destroyed) and UNWIND_HINT shouldn't be added. Signed-off-by: Peter Zijlstra (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li

[PATCH v10 36/38] x86/fred: Add fred_syscall_init()

From: "H. Peter Anvin (Intel)" Add a syscall initialization function fred_syscall_init() for FRED, and this is really just to skip setting up SYSCALL/SYSENTER related MSRs, e.g., MSR_LSTAR and invalidate SYSENTER configurations, because FRED uses the ring 3 FRED entrypoint for SYSCALL and

[PATCH v10 24/38] x86/idtentry: Incorporate definitions/declarations of the FRED entries

FRED and IDT can share most of the definitions and declarations so that in the majority of cases the actual handler implementation is the same. The differences are the exceptions where FRED stores exception related information on the stack and the sysvec implementations as FRED can handle

[PATCH v10 25/38] x86/fred: Add a debug fault entry stub for FRED

From: "H. Peter Anvin (Intel)" When occurred on different ring level, i.e., from user or kernel context, #DB needs to be handled on different stack: User #DB on current task stack, while kernel #DB on a dedicated stack. This is exactly how FRED event delivery invokes an exception handler: ring 3

[PATCH v10 22/38] x86/fred: Allow single-step trap and NMI when starting a new task

From: "H. Peter Anvin (Intel)" Entering a new task is logically speaking a return from a system call (exec, fork, clone, etc.). As such, if ptrace enables single stepping a single step exception should be allowed to trigger immediately upon entering user space. This is not optional. NMI should

[PATCH v10 23/38] x86/fred: Make exc_page_fault() work for FRED

From: "H. Peter Anvin (Intel)" On a FRED system, the faulting address (CR2) is passed on the stack, to avoid the problem of transient state. Thus we get the page fault address from the stack instead of CR2. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Thomas

[PATCH v10 35/38] x86/syscall: Split IDT syscall setup code into idt_syscall_init()

Split IDT syscall setup code into idt_syscall_init() to make it cleaner to add FRED syscall setup code. Suggested-by: Thomas Gleixner Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kernel/cpu/common.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git

[PATCH v10 37/38] x86/fred: Add FRED initialization functions

From: "H. Peter Anvin (Intel)" Add cpu_init_fred_exceptions() to: - Set FRED entrypoints for events happening in ring 0 and 3. - Specify the stack level for IRQs occurred ring 0. - Specify dedicated event stacks for #DB/NMI/#MCE/#DF. - Enable FRED and invalidtes IDT. - Force 32-bit

[PATCH v10 20/38] x86/fred: Disallow the swapgs instruction when FRED is enabled

From: "H. Peter Anvin (Intel)" SWAPGS is no longer needed thus NOT allowed with FRED because FRED transitions ensure that an operating system can _always_ operate with its own GS base address: - For events that occur in ring 3, FRED event delivery swaps the GS base address with the

[PATCH v10 38/38] x86/fred: Invoke FRED initialization code to enable FRED

From: "H. Peter Anvin (Intel)" Let cpu_init_exception_handling() call cpu_init_fred_exceptions() to initialize FRED. However if FRED is unavailable or disabled, it falls back to set up TSS IST and initialize IDT. Signed-off-by: H. Peter Anvin (Intel) Co-developed-by: Xin Li Tested-by: Shan

[PATCH v10 21/38] x86/fred: No ESPFIX needed when FRED is enabled

From: "H. Peter Anvin (Intel)" Because FRED always restores the full value of %rsp, ESPFIX is no longer needed when it's enabled. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kernel/espfix_64.c | 8 1 file changed, 8 insertions(+)

[PATCH v10 27/38] x86/fred: Add a machine check entry stub for FRED

Like #DB, when occurred on different ring level, i.e., from user or kernel context, #MCE needs to be handled on different stack: User #MCE on current task stack, while kernel #MCE on a dedicated stack. This is exactly how FRED event delivery invokes an exception handler: ring 3 event on level 0

[PATCH v10 33/38] x86/entry: Add fred_entry_from_kvm() for VMX to handle IRQ/NMI

In IRQ/NMI induced VM exits, KVM VMX needs to execute the respective handlers, which requires the software to create a FRED stack frame, and use it to invoke the handlers. Add fred_irq_entry_from_kvm() for this job. Export fred_entry_from_kvm() because VMX can be compiled as a module.

[PATCH v10 29/38] x86/traps: Add sysvec_install() to install a system interrupt handler

From: "H. Peter Anvin (Intel)" Add sysvec_install() to install a system interrupt handler into the IDT or the FRED system interrupt handler table. Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v8: * Introduce a macro sysvec_install() to derive the asm handler name from a C

[PATCH v10 34/38] KVM: VMX: Call fred_entry_from_kvm() for IRQ/NMI handling

When FRED is enabled, call fred_entry_from_kvm() to handle IRQ/NMI in IRQ/NMI induced VM exits. Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kvm/vmx/vmx.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c

[PATCH v10 16/38] x86/ptrace: Add FRED additional information to the pt_regs structure

FRED defines additional information in the upper 48 bits of cs/ss fields. Therefore add the information definitions into the pt_regs structure. Specially introduce a new structure fred_ss to denote the FRED flags above SS selector, which avoids FRED_SSX_ macros and makes the code simpler and

[PATCH v10 18/38] x86/fred: Reserve space for the FRED stack frame

From: "H. Peter Anvin (Intel)" When using FRED, reserve space at the top of the stack frame, just like i386 does. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/thread_info.h | 12 +--- 1 file changed, 9 insertions(+), 3

[PATCH v10 17/38] x86/fred: Add a new header file for FRED definitions

From: "H. Peter Anvin (Intel)" Add a header file for FRED prototypes and definitions. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v6: * Replace pt_regs csx flags prefix FRED_CSL_ with FRED_CSX_. --- arch/x86/include/asm/fred.h | 68

[PATCH v10 13/38] x86/cpu: Add X86_CR4_FRED macro

From: "H. Peter Anvin (Intel)" Add X86_CR4_FRED macro for the FRED bit in %cr4. This bit must not be changed after initialization, so add it to the pinned CR4 bits. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v9: * Avoid a type cast by

[PATCH v10 19/38] x86/fred: Update MSR_IA32_FRED_RSP0 during task switch

From: "H. Peter Anvin (Intel)" MSR_IA32_FRED_RSP0 is used during ring 3 event delivery, and needs to be updated to point to the top of next task stack during task switch. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/switch_to.h |

[PATCH v10 15/38] x86/ptrace: Cleanup the definition of the pt_regs structure

struct pt_regs is hard to read because the member or section related comments are not aligned with the members. The 'cs' and 'ss' members of pt_regs are type of 'unsigned long' while in reality they are only 16-bit wide. This works so far as the remaining space is unused, but FRED will use the

[PATCH v10 12/38] x86/objtool: Teach objtool about ERET[US]

From: "H. Peter Anvin (Intel)" Update the objtool decoder to know about the ERET[US] instructions (type INSN_CONTEXT_SWITCH). Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- tools/objtool/arch/x86/decode.c | 19 ++- 1 file changed, 14

[PATCH v10 14/38] x86/cpu: Add MSR numbers for FRED configuration

From: "H. Peter Anvin (Intel)" Add MSR numbers for the FRED configuration registers per FRED spec 5.0. Originally-by: Megha Dey Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/msr-index.h | 13 -

[PATCH v10 02/38] x86/opcode: Add the WRMSRNS instruction to the x86 opcode map

Add the opcode used by WRMSRNS, which is the non-serializing version of WRMSR and may replace it to improve performance, to the x86 opcode map. Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/lib/x86-opcode-map.txt | 2 +- tools/arch/x86/lib/x86-opcode-map.txt | 2 +- 2 files

[PATCH v10 10/38] x86/fred: Disable FRED by default in its early stage

To enable FRED, a new kernel command line option "fred" needs to be added. Tested-by: Shan Kang Signed-off-by: Xin Li --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ arch/x86/kernel/cpu/common.c| 3 +++ 2 files changed, 6 insertions(+) diff --git

[PATCH v10 08/38] x86/cpufeatures: Add the cpu feature bit for FRED

From: "H. Peter Anvin (Intel)" Any FRED CPU will always have the following features as its baseline: 1) LKGS, load attributes of the GS segment but the base address into the IA32_KERNEL_GS_BASE MSR instead of the GS segment’s descriptor cache. 2) WRMSRNS, non-serializing WRMSR for

[PATCH v10 09/38] x86/fred: Disable FRED support if CONFIG_X86_FRED is disabled

From: "H. Peter Anvin (Intel)" Add CONFIG_X86_FRED to to make cpu_feature_enabled() work correctly with FRED. Originally-by: Megha Dey Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/disabled-features.h | 8 +++-

[PATCH v10 00/38] x86: enable FRED for x86-64

This patch set enables the Intel flexible return and event delivery (FRED) architecture for x86-64. The FRED architecture defines simple new transitions that change privilege level (ring transitions). The FRED architecture was designed with the following goals: 1) Improve overall performance and

[PATCH v10 11/38] x86/opcode: Add ERET[US] instructions to the x86 opcode map

From: "H. Peter Anvin (Intel)" ERETU returns from an event handler while making a transition to ring 3, and ERETS returns from an event handler while staying in ring 0. Add instruction opcodes used by ERET[US] to the x86 opcode map; opcode numbers are per FRED spec v5.0. Signed-off-by: H.

[PATCH v10 06/38] Documentation/x86/64: Add a documentation for FRED

Briefly introduce FRED, and its advantages compared to IDT. Signed-off-by: Xin Li --- Documentation/arch/x86/x86_64/fred.rst | 98 + Documentation/arch/x86/x86_64/index.rst | 1 + 2 files changed, 99 insertions(+) create mode 100644

[PATCH v10 04/38] x86/entry: Remove idtentry_sysvec from entry_{32,64}.S

idtentry_sysvec is really just DECLARE_IDTENTRY defined in , no need to define it separately. Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/entry/entry_32.S | 4 arch/x86/entry/entry_64.S | 8 arch/x86/include/asm/idtentry.h | 2 +- 3 files changed, 1

[PATCH v10 01/38] x86/cpufeatures: Add the cpu feature bit for WRMSRNS

WRMSRNS is an instruction that behaves exactly like WRMSR, with the only difference being that it is not a serializing instruction by default. Under certain conditions, WRMSRNS may replace WRMSR to improve performance. Add the CPU feature bit for WRMSRNS. Tested-by: Shan Kang Signed-off-by: Xin

[PATCH v10 05/38] x86/trapnr: Add event type macros to

Intel VT-x classifies events into eight different types, which is inherited by FRED for event identification. As such, event type becomes a common x86 concept, and should be defined in a common x86 header. Add event type macros to , and use it in . Suggested-by: H. Peter Anvin (Intel)

[PATCH v10 03/38] x86/msr: Add the WRMSRNS instruction support

Add an always inline API __wrmsrns() to embed the WRMSRNS instruction into the code. Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/msr.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index

[PATCH v10 07/38] x86/fred: Add Kconfig option for FRED (CONFIG_X86_FRED)

From: "H. Peter Anvin (Intel)" Add the configuration option CONFIG_X86_FRED to enable FRED. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/Kconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig

Re: [PATCH] Revert "EDAC/mce_amd: Do not load edac_mce_amd module on guests"

On 9/13/23 11:50 AM, Luck, Tony wrote: >> Also, please note that the EDAC modules don't handle MCE events >> directly. They act on information passed from the MCE subsystem. >> >> Furthermore, there are other EDAC modules that have the same !hypervisor >> check, so why change only this one? > >

Re: [PATCH] Revert "EDAC/mce_amd: Do not load edac_mce_amd module on guests"

On 9/7/23 11:59 PM, Borislav Petkov wrote: > On Thu, Sep 07, 2023 at 08:08:00PM -0700, Elliott Mitchell wrote: >> This reverts commit 767f4b620edadac579c9b8b6660761d4285fa6f9. >> >> There are at least 3 valid reasons why a VM may see MCE events/registers. > > Hmm, so they all read like a bunch of

[xen-unstable test] 182997: tolerable FAIL - PUSHED

flight 182997 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/182997/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 182955

[PATCH v3 2/2] xen/arm: Enlarge identity map space to 127TB

On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores), the physical memory regions are: DRAM memory regions: Node[0] Region[0]: 0x8000 - 0x Node[0] Region[1]: 0x0800 - 0x08007fff Node[0] Region[2]: 0x0801 - 0x0807

[PATCH v3 1/2] xen/arm: Add macro XEN_VM_MAPPING

Xen maps the virtual memory space starting from L0 slot 4, so it's open coded for macros with the offset '4'. For more readable, add a new macro XEN_VM_MAPPING which defines the start slot for Xen virtual memory mapping, and all virtual memory regions are defined based on it. Signed-off-by: Leo

[PATCH v3 0/2] xen/arm: Enlarge identity map space

The latest Xen fails to boot on ADLink AVA platform. Alexey Klimov root caused the issue is related with the commit 1c78d76b67 ("xen/arm64: mm: Introduce helpers to prepare/enable/disable"). This is because on ADLink AVA platform, it loads Xen hypervisor to the address above 8TB and hence causes

Re: [PATCH v9 04/16] vpci: add hooks for PCI device assign/de-assign

Hi, Jan Beulich writes: > On 13.09.2023 01:41, Volodymyr Babchuk wrote: >> Jan Beulich writes: >>> On 30.08.2023 01:19, Volodymyr Babchuk wrote: @@ -1481,6 +1488,13 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32 flag) if ( pdev->broken && d

Re: [XEN PATCH] x86/ACPI: Ignore entries with invalid APIC IDs when parsing MADT

On Wed, 13 Sep 2023, George Dunlap wrote: > On Tue, Sep 12, 2023 at 8:57 AM Thomas Gleixner wrote: > > > > On Mon, Sep 11 2023 at 19:24, Andrew Cooper wrote: > > > Furthermore, cursory testing that Thomas did for the Linux topology work > > > demonstrates that it is broken anyway for reasons

[PATCH] docs/misra: accept 11.7 and 11.8

From: Stefano Stabellini As per the last MISRA C group discussion, let's accept 11.7 (for which we have no violations) and 11.8. Signed-off-by: Stefano Stabellini --- docs/misra/rules.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/docs/misra/rules.rst

Re: [XEN PATCH] xen/libelf: address violations of MISRA C:2012 RUles 8.2 and 8.3

On Wed, 13 Sep 2023, Julien Grall wrote: > On 13/09/2023 13:41, Federico Serafini wrote: > > On 13/09/23 14:29, Federico Serafini wrote: > > > Add missing parameter names and make function declarations and > > > definitions consistent. No functional change. > > > > > > Signed-off-by: Federico

Re: [PATCH 1/3] arm/xen: remove lazy mode related definitions

On Wed, 13 Sep 2023, Juergen Gross wrote: > include/xen/arm/hypervisor.h contains definitions related to paravirt > lazy mode, which are used nowhere in the code. > > All paravirt lazy mode related users are in x86 code, so remove the > definitions on Arm side. > > Signed-off-by: Juergen Gross

Re: [ImageBuilder PATCH v3] uboot-script-gen: use size from arm64 Image header

On Wed, 13 Sep 2023, Stewart Hildebrand wrote: > There is a corner case where the filesizes of the xen and Linux kernel images > are not sufficient. These binaries likely contain NOLOAD sections (e.g. bss), > which are not accounted in the filesize. > > Check for the presence of an arm64 kernel

[linux-linus test] 182992: regressions - trouble: blocked/broken/fail/pass

flight 182992 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/182992/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386 broken build-i386-pvops

Re: (Debian) Bug#1051862: server flooded with xen_mc_flush warnings with xen 4.17 + linux 6.1

Hi Radoslav, Thanks for your report... Hi Juergen, Boris and xen-devel, At Debian, we got the report below. (Also at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051862) This hardware, with only Xen and Dom0 running is hitting the failed multicall warning and logging in

RE: [EXT] Re: xen arm64 low power sleep support

On Wed, 13 Sep 2023, Anthony Chan wrote: > On Mon, 11 Sep 2023, Stefano Stabellini wrote: > > On Mon, 11 Sep 2023, Anthony Chan wrote: > > > On Wed, 6 Sep 2023, Stefano Stabellini wrote: > > > > On Wed, 6 Sep 2023, Anthony Chan wrote: > > > > > Thanks, I've tried patches that stemmed from that

Re: [PATCH 8/8] x86/spec-ctrl: Mitigate the Zen1 DIV leakge

On Wed, Sep 13, 2023 at 09:27:58PM +0100, Andrew Cooper wrote: > diff --git a/xen/arch/x86/include/asm/cpufeatures.h > b/xen/arch/x86/include/asm/cpufeatures.h > index da0593de8542..724de2e11db4 100644 > --- a/xen/arch/x86/include/asm/cpufeatures.h > +++ b/xen/arch/x86/include/asm/cpufeatures.h >

Re: [PATCH 8/8] x86/spec-ctrl: Mitigate the Zen1 DIV leakge

On 13/09/2023 9:27 pm, Andrew Cooper wrote: > @@ -955,6 +960,40 @@ static void __init srso_calculations(bool hw_smt_enabled) > setup_force_cpu_cap(X86_FEATURE_SRSO_NO); > } > > +/* > + * Div leakage is specific to the AMD Zen1 microarchitecure. Use STIBP as a > + * heuristic to select

Re: [Xen PATCH] x86/amd: do not expose HWCR.TscFreqSel to guests

On Wed, Sep 13 2023 at 12:02, Andrew Cooper wrote: > The PSTATE MSRs are entirely model specific, fully read/write, and the > Enable bit is not an enable bit; its a "not valid yet" bit that firmware > is required to adjust to be consistent across the coherency fabric. > > Linux is simply wrong

[PATCH 8/8] x86/spec-ctrl: Mitigate the Zen1 DIV leakge

In the Zen1 microarchitecure, there is one divider in the pipeline which services uops from both threads. In the case of #DE, the latched result from the previous DIV to execute will be forwarded speculatively. This is an interesting covert channel that allows two threads to communicate without

[PATCH 0/8] x86/spec-ctrl: AMD DIV fix, and VERW prerequisite bugfixes

Patch 8 is the XSA-439 fix for the AMD DIV issue, disclosed insufficiently ahead of August 8th for us to prepare a fix for the embargo. Patches 1 thru 7 are prerequisites, identified while trying to write patch 8. All 8 patches are for all security trees. Andrew Cooper (8): x86/spec-ctrl: Fix

[PATCH 7/8] x86/spec-ctrl: Issue VERW during IST exit to Xen

There is a corner case where e.g. an NMI hitting an exit-to-guest path after SPEC_CTRL_EXIT_TO_* would have run the entire NMI handler *after* the VERW flush to scrub potentially sensitive data from uarch buffers. In order to compensate, issue VERW when exiting to Xen from an IST entry.

[PATCH 5/8] x86/entry: Adjust restore_all_xen to hold stack_end in %r14

All other SPEC_CTRL_{ENTRY,EXIT}_* helpers hold stack_end in %r14. Adjust it for consistency, freeing up %rbx to be used differently. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu --- xen/arch/x86/include/asm/spec_ctrl_asm.h | 8

[PATCH 2/8] x86/spec-ctrl: Fold DO_SPEC_CTRL_EXIT_TO_XEN into it's single user

With the SPEC_CTRL_EXIT_TO_XEN{,_IST} confusion fixed, it's now obvious that there's only a single EXIT_TO_XEN path. Fold DO_SPEC_CTRL_EXIT_TO_XEN into SPEC_CTRL_EXIT_TO_XEN to simplify further fixes. When merging labels, switch the name to .L\@_skip_sc_msr as "skip" on its own is going to be

[PATCH 6/8] x86/entry: Track the IST-ness of an entry for the exit paths

Use %r12 to hold an ist_exit boolean. This register is zero elsewhere in the entry/exit asm, so it only needs setting in the IST path. As this is subtle and fragile, add check_ist_exit() to be used in debugging builds to cross-check that the ist_exit boolean matches the entry vector. Write

[PATCH 4/8] x86/spec-ctrl: Extend all SPEC_CTRL_{ENTER,EXIT}_* comments

... to better explain how they're used. Doing so highlights that SPEC_CTRL_EXIT_TO_XEN is missing a VERW flush for the corner case when e.g. an NMI hits late in an exit-to-guest path. Leave a TODO, which will be addressed in subsequent patches which arrange for DO_COND_VERW to be safe within

[PATCH 1/8] x86/spec-ctrl: Fix confusion between SPEC_CTRL_EXIT_TO_XEN{,_IST}

c/s 3fffaf9c13e9 ("x86/entry: Avoid using alternatives in NMI/#MC paths") dropped the only user, leaving behind the (incorrect) implication that Xen had split exit paths. Delete the unused SPEC_CTRL_EXIT_TO_XEN and rename SPEC_CTRL_EXIT_TO_XEN_IST to SPEC_CTRL_EXIT_TO_XEN for consistency. No

[PATCH 3/8] x86/spec-ctrl: Turn the remaining SPEC_CTRL_{ENTRY,EXIT}_* into asm macros

These have grown more complex over time, with some already having been converted. Provide full Requires/Clobbers comments, otherwise missing at this level of indirection. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu ---

Re: [PATCH v3 0/4] virtio-blk: use blk_io_plug_call() instead of notification BH

On Wed, Sep 13, 2023 at 04:00:41PM -0400, Stefan Hajnoczi wrote: > v3: > - Add comment pointing to API documentation in .c file [Philippe] > - Add virtio_notify_irqfd_deferred_fn trace event [Ilya] > - Remove outdated #include [Ilya] > v2: > - Rename blk_io_plug() to defer_call() and move it to

[PATCH v3 3/4] virtio: use defer_call() in virtio_irqfd_notify()

virtio-blk and virtio-scsi invoke virtio_irqfd_notify() to send Used Buffer Notifications from an IOThread. This involves an eventfd write(2) syscall. Calling this repeatedly when completing multiple I/O requests in a row is wasteful. Use the defer_call() API to batch together

[PATCH v3 2/4] util/defer-call: move defer_call() to util/

The networking subsystem may wish to use defer_call(), so move the code to util/ where it can be reused. As a reminder of what defer_call() does: This API defers a function call within a defer_call_begin()/defer_call_end() section, allowing multiple calls to batch up. This is a performance

[PATCH v3 1/4] block: rename blk_io_plug_call() API to defer_call()

Prepare to move the blk_io_plug_call() API out of the block layer so that other subsystems call use this deferred call mechanism. Rename it to defer_call() but leave the code in block/plug.c. The next commit will move the code out of the block layer. Suggested-by: Ilya Maximets Reviewed-by:

[PATCH v3 4/4] virtio-blk: remove batch notification BH

There is a batching mechanism for virtio-blk Used Buffer Notifications that is no longer needed because the previous commit added batching to virtio_notify_irqfd(). Note that this mechanism was rarely used in practice because it is only enabled when EVENT_IDX is not negotiated by the driver.

[PATCH v3 0/4] virtio-blk: use blk_io_plug_call() instead of notification BH

v3: - Add comment pointing to API documentation in .c file [Philippe] - Add virtio_notify_irqfd_deferred_fn trace event [Ilya] - Remove outdated #include [Ilya] v2: - Rename blk_io_plug() to defer_call() and move it to util/ so the net subsystem can use it [Ilya] - Add defer_call_begin()/end()

Re: [PATCH v2 2/4] util/defer-call: move defer_call() to util/

On Fri, Aug 18, 2023 at 10:31:40AM +0200, Philippe Mathieu-Daudé wrote: > Hi Stefan, > > On 17/8/23 17:58, Stefan Hajnoczi wrote: > > The networking subsystem may wish to use defer_call(), so move the code > > to util/ where it can be reused. > > > > As a reminder of what defer_call() does: > >

[libvirt test] 182989: regressions - trouble: blocked/broken/fail/pass

flight 182989 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/182989/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386 broken build-i386-pvops

Re: [PATCH v2 for-4.18?] x86: support data operand independent timing mode

Hi, On 11/09/2023 16:01, Jan Beulich wrote: [1] specifies a long list of instructions which are intended to exhibit timing behavior independent of the data they operate on. On certain hardware this independence is optional, controlled by a bit in a new MSR. Provide a command line option to

Re: [PATCH v2 for-4.18?] x86: support data operand independent timing mode

Hi, On 12/09/2023 07:21, Jan Beulich wrote: On 12.09.2023 02:48, Henry Wang wrote: On Sep 11, 2023, at 23:01, Jan Beulich wrote: --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -788,6 +788,14 @@ Specify the size of the console debug tr additionally a trace

Re: [PATCH v2] xen/arm: Skip Xen specific nodes/properties from hwdom /chosen node

Hi Michal, On 12/09/2023 11:53, Michal Orzel wrote: Skip the following Xen specific host device tree nodes/properties from being included into hardware domain /chosen node: - xen,static-heap: this property informs Xen about memory regions reserved exclusively as static heap, -

Community Guidelines

Hi all, I hope everyone is well. First and foremost, I want to express my appreciation for the dedication and hard work everyone has put into this project. It is evident that you have the best interests of the community at heart, and your contributions are invaluable. It is natural for

RE: [PATCH] Revert "EDAC/mce_amd: Do not load edac_mce_amd module on guests"

> Also, please note that the EDAC modules don't handle MCE events > directly. They act on information passed from the MCE subsystem. > > Furthermore, there are other EDAC modules that have the same !hypervisor > check, so why change only this one? The older Intel EDAC drivers translated system

RE: [EXT] Re: xen arm64 low power sleep support

On Mon, 11 Sep 2023, Stefano Stabellini wrote: > On Mon, 11 Sep 2023, Anthony Chan wrote: > > On Wed, 6 Sep 2023, Stefano Stabellini wrote: > > > On Wed, 6 Sep 2023, Anthony Chan wrote: > > > > Thanks, I've tried patches that stemmed from that discussion but > > > > unfortunately, doesn't resolve

[PATCH v2] x86/amd: do not expose HWCR.TscFreqSel to guests

OpenBSD 7.3 will unconditionally access HWCR if the TSC is reported as Invariant, and it will then attempt to also unconditionally access PSTATE0 if HWCR.TscFreqSel is set (currently the case on Xen). The relation between HWCR.TscFreqSel and PSTATE0 is not clearly written down in the PPR, but

[PATCH v7 2/2] xen/vpci: header: filter PCI capabilities

Currently, Xen vPCI only supports virtualizing the MSI and MSI-X capabilities. Hide all other PCI capabilities (including extended capabilities) from domUs for now, even though there may be certain devices/drivers that depend on being able to discover certain capabilities. We parse the physical

[PATCH v7 1/2] xen/vpci: header: status register handler

Introduce a handler for the PCI status register, with ability to mask the capabilities bit. The status register contains RsvdZ bits, read-only bits, and write-1-to-clear bits, so introduce bitmasks to handle these in vPCI. If a bit in the bitmask is set, then the special meaning applies:

[PATCH v7 0/2] vPCI capabilities filtering

This small series enables vPCI to filter which PCI capabilities we expose to a domU. This series adds vPCI register handlers within xen/drivers/vpci/header.c:init_bars(), along with some supporting functions. Note there are minor rebase conflicts with the in-progress vPCI series [1]. These

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

On Wed, Sep 13, 2023 at 4:18 PM Albert Esteve wrote: > > > On Wed, Sep 13, 2023 at 3:43 PM Akihiko Odaki > wrote: > >> On 2023/09/13 21:58, Albert Esteve wrote: >> > >> > >> > On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki > > > wrote: >> > >> > On 2023/09/13

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

On Wed, Sep 13, 2023 at 3:43 PM Akihiko Odaki wrote: > On 2023/09/13 21:58, Albert Esteve wrote: > > > > > > On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki > > wrote: > > > > On 2023/09/13 20:34, Albert Esteve wrote: > > > > > > > > > On Wed,

[ImageBuilder PATCH v3] uboot-script-gen: use size from arm64 Image header

There is a corner case where the filesizes of the xen and Linux kernel images are not sufficient. These binaries likely contain NOLOAD sections (e.g. bss), which are not accounted in the filesize. Check for the presence of an arm64 kernel image header, and get the effective image size from the

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

On 2023/09/13 21:58, Albert Esteve wrote: On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki > wrote: On 2023/09/13 20:34, Albert Esteve wrote: > > > On Wed, Sep 13, 2023 at 12:34 PM Akihiko Odaki mailto:akihiko.od...@daynix.com> >

Re: [Xen PATCH] x86/amd: do not expose HWCR.TscFreqSel to guests

On 13.09.2023 13:02, Andrew Cooper wrote: > On 13/09/2023 7:18 am, Jan Beulich wrote: >> On 12.09.2023 18:35, Andrew Cooper wrote: >>> On 12/09/2023 5:23 pm, Roger Pau Monne wrote: --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -240,8 +240,12 @@ int guest_rdmsr(struct vcpu *v,

Re: [ImageBuilder PATCH v2] uboot-script-gen: use size from arm64 Image header

Hi Stewart, On 13/09/2023 15:31, Stewart Hildebrand wrote: > On 9/13/23 03:27, Michal Orzel wrote: >> Hi Stewart, >> >> On 12/09/2023 22:43, Stewart Hildebrand wrote: >>> There is a corner case where the filesizes of the xen and Linux kernel >>> images >>> are not sufficient. These binaries

Re: [PATCH 2/3] x86/xen: move paravirt lazy code

On 13.09.23 15:26, Steven Rostedt wrote: On Wed, 13 Sep 2023 13:38:27 +0200 Juergen Gross wrote: diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h index 44a3f565264d..0577f0cdd231 100644 --- a/include/trace/events/xen.h +++ b/include/trace/events/xen.h @@ -6,26 +6,26 @@

Re: [ImageBuilder PATCH v2] uboot-script-gen: use size from arm64 Image header

On 9/13/23 03:27, Michal Orzel wrote: > Hi Stewart, > > On 12/09/2023 22:43, Stewart Hildebrand wrote: >> There is a corner case where the filesizes of the xen and Linux kernel images >> are not sufficient. These binaries likely contain NOLOAD sections (e.g. bss), >> which are not accounted in

Re: [PATCH] x86/amd: do not expose HWCR.TscFreqSel to guests

On 13.09.2023 12:50, Andrew Cooper wrote: > On 13/09/2023 8:50 am, Roger Pau Monné wrote: >> Hm, there's no written down note that TSC_FREQ_SEL implies PSTATE0 to >> be available (and PSTATE0 is not an architectural MSR), but I can see >> how a guest can expect to fetch the P0 frequency if it sees

Re: [PATCH 2/3] x86/xen: move paravirt lazy code

On Wed, 13 Sep 2023 13:38:27 +0200 Juergen Gross wrote: > diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h > index 44a3f565264d..0577f0cdd231 100644 > --- a/include/trace/events/xen.h > +++ b/include/trace/events/xen.h > @@ -6,26 +6,26 @@ > #define _TRACE_XEN_H > >

Re: [XEN PATCH] xen/libelf: address violations of MISRA C:2012 RUles 8.2 and 8.3

Hi, On 13/09/2023 13:41, Federico Serafini wrote: On 13/09/23 14:29, Federico Serafini wrote: Add missing parameter names and make function declarations and definitions consistent. No functional change. Signed-off-by: Federico Serafini There is a typo in the patch title (RUles), please

[ovmf test] 182996: all pass - PUSHED

flight 182996 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/182996/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf cdfe4310dda2a30b0ca05c8ede6896edce37a656 baseline version: ovmf

[xen-unstable test] 182987: regressions - trouble: broken/fail/pass

flight 182987 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/182987/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt broken test-amd64-i386-examine-uefi 5

  1   2   >