Re: [RFC][PATCH 0/6] x86: Fix suspend vs retbleed=stuff

Hi Peter, I tried your patches on both QEMU and my two (real) computers where s2ram with `retbleed=stuff` was failing and they wake up fine now. However, I think some minor reviews are needed: (1) I got a build error due to a symbol conflict between the `restore_registers` in

Re: [PATCH v2 6/8] x86/iommu: call pi_update_irte through an hvm_function callback

On 1/12/23 14:37, Jan Beulich wrote: On 12.01.2023 13:16, Jan Beulich wrote: On 04.01.2023 09:45, Xenia Ragiadakou wrote: --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2143,6 +2143,14 @@ static bool cf_check vmx_test_pir(const struct vcpu *v, uint8_t vec)

Re: [PATCH v2 6/8] x86/iommu: call pi_update_irte through an hvm_function callback

On 1/12/23 14:16, Jan Beulich wrote: On 04.01.2023 09:45, Xenia Ragiadakou wrote: --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2143,6 +2143,14 @@ static bool cf_check vmx_test_pir(const struct vcpu *v, uint8_t vec) return pi_test_pir(vec,

[PATCH v2 35/40] xen/mpu: destroy boot modules and early FDT mapping in MPU system

In MMU system, we will free all memory as boot modules, like kernel initramfs module, into heap, and it is not applicable in MPU system. Heap must be statically configured in Device tree, so it should not change. In MPU system, we destory MPU memory regions of boot modules. In MPU version of

[PATCH v2 24/40] xen/mpu: introduce "mpu,xxx-memory-section"

In MPU system, all kinds of resources, including system resource and domain resource must be statically configured in Device Tree, i.e, guest RAM must be statically allocated through "xen,static-mem" property under domain node. However, due to limited MPU protection regions and a wide variety of

[PATCH v2 28/40] xen/mpu: map boot module section in MPU system

In MPU system, we could not afford mapping a new MPU memory region with each new guest boot module, it will exhaust limited MPU memory regions very quickly. So we introduce `mpu,boot-module-section` for users to statically configure one big memory section or very few memory sections for all

[PATCH v2 25/40] xen/mpu: map MPU guest memory section before static memory initialization

Previous commit introduces a new device tree property "mpu,guest-memory-section" to define MPU guest memory section, which will mitigate the scattering of statically-configured guest RAM. We only need to set up MPU memory region mapping for MPU guest memory section to have access to all guest

[PATCH] xen/mpu: make Xen boot to idle on MPU systems(DNM)

From: Wei Chen As we have not implmented guest support in part#1 series of MPU support, Xen can not create any guest in boot time. So in this patch we make Xen boot to idle on MPU system for reviewer to test part#1 series. THIS PATCH IS ONLY FOR TESTING, NOT FOR REVIEWING. Signed-off-by: Wei

[PATCH v2 12/40] xen/mpu: introduce helpers for MPU enablement

We need a new helper for Xen to enable MPU in boot-time. The new helper is semantically consistent with the original enable_mmu. If the Background region is enabled, then the MPU uses the default memory map as the Background region for generating the memory attributes when MPU is disabled. Since

[PATCH v2 30/40] xen/mpu: disable VMAP sub-system for MPU systems

VMAP in MMU system, is used to remap a range of normal memory or device memory to another virtual address with new attributes for specific purpose, like ALTERNATIVE feature. Since there is no virtual address translation support in MPU system, we can not support VMAP in MPU system. So in this

[PATCH v2 21/40] xen/arm: move MMU-specific setup_mm to setup_mmu.c

setup_mm is used for Xen to setup memory management subsystem, like boot allocator, direct-mapping, xenheap, frametable and static memory pages. We could inherit some components seamlessly in MPU system like boot allocator, whilst we need to implement some components differently in MPU, like

[PATCH v2 33/40] xen/arm: check mapping status and attributes for MPU copy_from_paddr

From: Wei Chen We introduce map_page_to_xen_misc/unmap_page_to_xen_misc to temporarily map a page in Xen misc field to gain access, however, in MPU system, all resource is statically configured in Device Tree and already mapped at very early boot stage. When enabling map_page_to_xen_misc for

[PATCH v2 39/40] xen/mpu: re-order xen_mpumap in arch_init_finialize

In function init_done, we have finished the booting and we do the final clean-up working, including marking the section .data.ro_after_init read-only, free init text and init data section, etc. In MPU system, other than above operations, we also need to re-order Xen MPU memory region mapping

[PATCH v2 38/40] xen/mpu: implement setup_virt_paging for MPU system

For MMU system setup_virt_paging is used to configure stage 2 address translation, like IPA bits, VMID bits, etc. And this function is also doing the VMID allocator initializtion for later VM creation. Except for IPA bits and VMID bits, the setup_virt_paging function in MPU system should be also

[PATCH v2 29/40] xen/mpu: introduce mpu_memory_section_contains for address range check

We have already introduced "mpu,xxx-memory-section" to limit system/domain configuration, so we shall add check to verfify user's configuration. We shall check if any guest boot module is within the boot module section, including kernel module(BOOTMOD_KERNEL), device tree passthrough

[PATCH v2 31/40] xen/mpu: disable FIXMAP in MPU system

FIXMAP in MMU system is used to do special-purpose 4K mapping, like mapping early UART, temporarily mapping source codes for copy and paste (copy_from_paddr), ect. As there is no VMSA in MPU system, we do not support FIXMAP in MPU system. We deine !CONFIG_HAS_FIXMAP to provide empty stubbers for

[PATCH v2 26/40] xen/mpu: destroy an existing entry in Xen MPU memory mapping table

This commit expands xen_mpumap_update/xen_mpumap_update_entry to include destroying an existing entry. We define a new helper "control_xen_mpumap_region_from_index" to enable/disable the MPU region based on index. If region is within [0, 31], we could quickly disable the MPU region through

[PATCH v2 14/40] xen/arm64: head: Jump to the runtime mapping in enable_mm()

At the moment, on MMU system, enable_mm() will return to an address in the 1:1 mapping, then each path is responsible to switch to virtual runtime mapping. Then remove_identity_mapping() is called to remove all 1:1 mapping. Since remove_identity_mapping() is not necessary on MPU system, and we

[PATCH v2 18/40] xen/mpu: introduce helper access_protection_region

Each EL2 MPU protection region could be configured using PRBAR_EL2 and PRLAR_EL2. This commit introduces a new helper access_protection_region() to access EL2 MPU protection region, including both read/write operations. As explained in section G1.3.18 of the reference manual for AArch64v8R, a

[PATCH v2 23/40] xen/mpu: initialize frametable in MPU system

Xen is using page as the smallest granularity for memory managment. And we want to follow the same concept in MPU system. That is, structure page_info and the frametable which is used for storing and managing page_info is also required in MPU system. In MPU system, since there is no virtual

[PATCH v2 34/40] xen/mpu: free init memory in MPU system

This commit implements free_init_memory in MPU system, trying to keep the same strategy with MMU system. In order to inserting BRK instruction into init code section, which aims to provok a fault on purpose, we should change init code section permission to RW at first. Function

[PATCH v2 19/40] xen/mpu: populate a new region in Xen MPU mapping table

The new helper xen_mpumap_update() is responsible for updating an entry in Xen MPU memory mapping table, including creating a new entry, updating or destroying an existing one. This commit only talks about populating a new entry in Xen MPU mapping table( xen_mpumap). Others will be introduced in

[PATCH v2 13/40] xen/mpu: introduce unified function setup_early_uart to map early UART

In MMU system, we map the UART in the fixmap (when earlyprintk is used). However in MPU system, we map the UART with a transient MPU memory region. So we introduce a new unified function setup_early_uart to replace the previous setup_fixmap. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen

[PATCH v2 10/40] xen/arm: split MMU and MPU config files from config.h

From: Wei Chen Xen defines some global configuration macros for Arm in config.h. We still want to use it for Armv8-R systems, but there are some address related macros that are defined for MMU systems. These macros will not be used by MPU systems, Adding ifdefery with CONFIG_HAS_MPU to gate

[PATCH v2 32/40] xen/mpu: implement MPU version of ioremap_xxx

Function ioremap_xxx is normally being used to remap device address ranges in MMU system during device driver initialization. However, in MPU system, virtual translation is not supported and device memory layout is statically configured in Device Tree, and being mapped at very early stage. So

[PATCH v2 37/40] xen/mpu: move MMU specific P2M code to p2m_mmu.c

Current P2M implementation is designed for MMU system. Only a few codes can be shared by MPU system, like P2M pool, IPA, etc We move the MMU-specific codes into p2m_mmu.c, and place stub functions in p2m_mpu.c which wait for implementing on the first usage. And we keep generic codes in p2m.c We

[PATCH v2 22/40] xen/mpu: implement MPU version of setup_mm in setup_mpu.c

In MPU system, system RAM shall be statically partitioned into different functionality section in Device Tree at the very beginning, including static xenheap, guest memory section, boot-module section, etc. So using a virtual contigious memory region to do direct-mapping for the whole system RAM

[PATCH v2 27/40] xen/mpu: map device memory resource in MPU system

In MPU system, we could not afford mapping a new MPU memory region with each new device, it will exhaust limited MPU memory regions very quickly. So we introduce `mpu,device-memory-section` for users to statically configure the whole system device memory with the least number of memory regions in

[PATCH v2 15/40] xen/arm: move MMU-specific memory management code to mm_mmu.c/mm_mmu.h

From: Wei Chen To make the code readable and maintainable, we move MMU-specific memory management code from mm.c to mm_mmu.c and move MMU-specific definitions from mm.h to mm_mmu.h. Later we will create mm_mpu.h and mm_mpu.c for MPU-specific memory management code. This will avoid lots of #ifdef

[PATCH v2 40/40] xen/mpu: add Kconfig option to enable Armv8-R AArch64 support

Introduce a Kconfig option to enable Armv8-R64 architecture support. STATIC_MEMORY and HAS_MPU will be selected by ARM_V8R by default, because Armv8-R64 only has PMSAv8-64 on secure-EL2 and only supports statically configured system. Signed-off-by: Wei Chen --- xen/arch/arm/Kconfig | 13

[PATCH v2 17/40] xen/mpu: plump virt/maddr/mfn convertion in MPU system

virt_to_maddr and maddr_to_virt are used widely in Xen code. So even there is no VMSA in MPU system, we keep the interface name to stay the same code flow. We move the existing virt/maddr convertion from mm.h to mm_mmu.h. And the MPU version of virt/maddr convertion is simple, returning the input

[PATCH v2 36/40] xen/mpu: Use secure hypervisor timer for AArch64v8R

As AArch64v8R only has one secure state, we have to use secure EL2 hypervisor timer for Xen in secure EL2. In this patch, we introduce a Kconfig option ARM_SECURE_STATE. With this new Kconfig option, we can re-define the timer's system register name in different secure state, but keep the timer

[PATCH v2 20/40] xen/mpu: plump early_fdt_map in MPU systems

In MPU system, device tree binary can be packed with Xen image through CONFIG_DTB_FILE, or provided by bootloader through x0. In MPU system, each section in xen.lds.S is PAGE_SIZE aligned. So in order to not overlap with the previous BSS section, dtb section should be made page-aligned too. We

[PATCH v2 16/40] xen/arm: introduce setup_mm_mappings

Function setup_pagetables is responsible for boot-time pagetable setup in MMU system. But in MPU system, we have already built up start-of-day Xen MPU memory region mapping at the very beginning in assembly. So in order to keep only one codeflow in arm/setup.c, setup_mm_mappings , with a more

[PATCH v2 11/40] xen/mpu: build up start-of-day Xen MPU memory region map

From: Penny Zheng The start-of-day Xen MPU memory region layout shall be like as follows: xen_mpumap[0] : Xen text xen_mpumap[1] : Xen read-only data xen_mpumap[2] : Xen read-only after init data xen_mpumap[3] : Xen read-write data xen_mpumap[4] : Xen BSS .. xen_mpumap[max_xen_mpumap - 2]:

[PATCH v2 09/40] xen/arm: decouple copy_from_paddr with FIXMAP

From: Wei Chen copy_from_paddr will map a page to Xen's FIXMAP_MISC area for temporary access. But for those systems do not support VMSA, they can not implement set_fixmap/clear_fixmap, that means they can't always use the same virtual address for source address. In this case, we introduce to

[PATCH v2 08/40] xen/arm: use PA == VA for EARLY_UART_VIRTUAL_ADDRESS on Armv-8R

From: Wei Chen There is no VMSA support on Armv8-R AArch64, so we can not map early UART to FIXMAP_CONSOLE. Instead, we use PA == VA to define EARLY_UART_VIRTUAL_ADDRESS on Armv8-R AArch64. Signed-off-by: Wei Chen --- 1. New patch --- xen/arch/arm/include/asm/early_printk.h | 12

[PATCH v2 06/40] xen/arm64: move MMU related code from head.S to head_mmu.S

From: Wei Chen There are lots of MMU specific code in head.S. This code will not be used in MPU systems. If we use #ifdef to gate them, the code will become messy and hard to maintain. So we move MMU related code to head_mmu.S, and keep common code still in head.S. And some assembly macros that

[PATCH v2 07/40] xen/arm64: add .text.idmap for Xen identity map sections

From: Wei Chen Only the first 4KB of Xen image will be mapped as identity (PA == VA). At the moment, Xen guarantees this by having everything that needs to be used in the identity mapping in head.S before _end_boot and checking at link time if this fits in 4KB. In previous patch, we have moved

[PATCH v2 05/40] xen/arm64: prepare for moving MMU related code from head.S

From: Wei Chen We want to reuse head.S for MPU systems, but there are some code implemented for MMU systems only. We will move such code to another MMU specific file. But before that, we will do some preparations in this patch to make them easier for reviewing: 1. Fix the indentations of code

[PATCH v2 04/40] xen/arm: add an option to define Xen start address for Armv8-R

From: Wei Chen On Armv8-A, Xen has a fixed virtual start address (link address too) for all Armv8-A platforms. In an MMU based system, Xen can map its loaded address to this virtual start address. So, on Armv8-A platforms, the Xen start address does not need to be configurable. But on Armv8-R

[PATCH v2 03/40] xen/arm: adjust Xen TLB helpers for Armv8-R64 PMSA

From: Wei Chen >From Arm ARM Supplement of Armv8-R AArch64 (DDI 0600A) [1], section D1.6.2 TLB maintenance instructions, we know that Armv8-R AArch64 permits an implementation to cache stage 1 VMSAv8-64 and stage 2 PMSAv8-64 attributes as a common entry for the Secure EL1&0 translation regime.

[PATCH v2 00/41] xen/arm: Add Armv8-R64 MPU support to Xen - Part#1

The Armv8-R architecture profile was designed to support use cases that have a high sensitivity to deterministic execution. (e.g. Fuel Injection, Brake control, Drive trains, Motor control etc) Arm announced Armv8-R in 2013, it is the latest generation Arm architecture targeted at the Real-time

[PATCH v2 01/40] xen/arm: remove xen_phys_start and xenheap_phys_end from config.h

From: Wei Chen These two variables are stale variables, they only have declarations in config.h, they don't have any definition and no any code is using these two variables. So in this patch, we remove them from config.h. Signed-off-by: Wei Chen Acked-by: Julien Grall --- v1 -> v2: 1. Add Ab.

[PATCH v2 02/40] xen/arm: make ARM_EFI selectable for Arm64

From: Wei Chen Currently, ARM_EFI will mandatorily selected by Arm64. Even if the user knows for sure that their images will not start in the EFI environment, they can't disable the EFI support for Arm64. This means there will be about 3K lines unused code in their images. So in this patch, we

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

On 1/12/23 6:03 PM, Michael S. Tsirkin wrote: > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote: >> I think the change Michael suggests is very minimalistic: Move the if >> condition around xen_igd_reserve_slot() into the function itself and >> always call it there unconditionally

S3 under Xen regression between 6.1.1 and 6.1.3

Hi, 6.1.3 as PV dom0 crashes when attempting to suspend. 6.1.1 works. The crash: [ 348.284004] PM: suspend entry (deep) [ 348.289532] Filesystems sync: 0.005 seconds [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 348.292457] OOM killer

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

flight 175739 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175739/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu broken test-armhf-armhf-xl-multivcpu 5

[xen-unstable-smoke test] 175748: trouble: broken/pass

flight 175748 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175748/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken

Re: [GIT PULL] xen: branch for v6.2-rc4

The pull request you sent on Wed, 11 Jan 2023 13:25:01 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-6.2-rc4-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/bad8c4a850eaf386df681d951e3afc06bf1c7cf8 Thank you! -- Deet-doot-dot, I

[qemu-mainline test] 175743: tolerable FAIL - PUSHED

flight 175743 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175743/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail in 175735 pass in 175743 test-amd64-i386-pair 11

Re: [PATCH 06/22] x86: map/unmap pages in restore_all_guests

Hi Jan, On 04/01/2023 10:27, Jan Beulich wrote: On 23.12.2022 13:22, Julien Grall wrote: Hi, On 22/12/2022 11:12, Jan Beulich wrote: On 16.12.2022 12:48, Julien Grall wrote: --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -165,7 +165,24 @@ restore_all_guest:

Re: [PATCH 05/22] x86/srat: vmap the pages for acpi_slit

Hi, On 04/01/2023 10:23, Jan Beulich wrote: On 23.12.2022 12:31, Julien Grall wrote: On 20/12/2022 15:30, Jan Beulich wrote: On 16.12.2022 12:48, Julien Grall wrote: From: Hongyan Xia This avoids the assumption that boot pages are in the direct map. Signed-off-by: Hongyan Xia

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote: > I think the change Michael suggests is very minimalistic: Move the if > condition around xen_igd_reserve_slot() into the function itself and > always call it there unconditionally -- basically turning three lines > into one. Since

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

Am 12. Januar 2023 20:11:54 UTC schrieb Chuck Zmudzinski : >On 1/12/23 2:18 PM, Bernhard Beschow wrote: >> >> >> Am 11. Januar 2023 15:40:24 UTC schrieb Chuck Zmudzinski : >>>On 1/10/23 3:16 AM, Michael S. Tsirkin wrote: On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:

Re: [PATCH v3 15/18] xen/arm64: mm: Introduce helpers to prepare/enable/disable the identity mapping

Hi, On 13/12/2022 01:41, Stefano Stabellini wrote: diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index fdbf68aadcaa..e7a80fecec14 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -168,6 +168,17 @@ int

Re: [RFC][PATCH 2/6] x86/power: Inline write_cr[04]()

On Thu, Jan 12, 2023 at 03:31:43PM +0100, Peter Zijlstra wrote: > Since we can't do CALL/RET until GS is restored and CR[04] pinning is > of dubious value in this code path, simply write the stored values. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kees Cook -- Kees Cook

[linux-linus test] 175737: regressions - FAIL

flight 175737 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175737/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit1 8 xen-boot fail REGR. vs. 173462

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

On 1/12/23 2:18 PM, Bernhard Beschow wrote: > > > Am 11. Januar 2023 15:40:24 UTC schrieb Chuck Zmudzinski : >>On 1/10/23 3:16 AM, Michael S. Tsirkin wrote: >>> On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote: Intel specifies that the Intel IGD must occupy slot 2 on the PCI

Re: [PATCH] x86/paravirt: merge activate_mm and dup_mmap callbacks

On 1/12/23 10:21 AM, Juergen Gross wrote: The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are sharing the same implementations in all cases: for Xen PV guests they are pinning the PGD of the new mm_struct, and for all other cases they are a NOP. So merge them to a common

Re: [PATCH v3 08/18] xen/arm32: head: Introduce an helper to flush the TLBs

On 14/12/2022 14:24, Michal Orzel wrote: Hi Julien, Hi Michal, On 12/12/2022 10:55, Julien Grall wrote: From: Julien Grall The sequence for flushing the TLBs is 4 instruction long and often requires an explanation how it works. So create an helper and use it in the boot code

[xen-unstable-smoke test] 175746: tolerable all pass - PUSHED

flight 175746 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175746/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

Am 11. Januar 2023 15:40:24 UTC schrieb Chuck Zmudzinski : >On 1/10/23 3:16 AM, Michael S. Tsirkin wrote: >> On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote: >>> Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus, >>> as noted in docs/igd-assign.txt in the

[ovmf test] 175747: all pass - PUSHED

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

Re: [PATCH v2 3/8] x86/iommu: iommu_igfx, iommu_qinval and iommu_snoop are VT-d specific

On 12/01/2023 3:43 pm, Xenia Ragiadakou wrote: > > On 1/12/23 13:49, Xenia Ragiadakou wrote: >> >> On 1/12/23 13:31, Jan Beulich wrote: >>> On 04.01.2023 09:44, Xenia Ragiadakou wrote: >>> --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -74,9 +74,13 @@ extern enum

Re: [PATCH] include/types: move stdlib.h-kind types to common header

Hi Jan, On 12/01/2023 14:01, Jan Beulich wrote: size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined on any ports Xen might gain. In particular I hope new ports can rely on __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler. Signed-off-by: Jan Beulich

Re: [PATCH v2 1/8] x86/boot: Sanitise PKRU on boot

On 12/01/2023 12:47 pm, Jan Beulich wrote: > On 10.01.2023 18:18, Andrew Cooper wrote: >> While the reset value of the register is 0, it might not be after kexec/etc. >> If PKEY0.{WD,AD} have leaked in from an earlier context, construction of a PV >> dom0 will explode. >> >> Sequencing wise, this

Proposal for consistent Kconfig usage by the hypervisor build system

(re-sending with REST on Cc, as requested at the community call) At present we use a mix of Makefile and Kconfig driven capability checks for tool chain components involved in the building of the hypervisor. What approach is used where is in some part a result of the relatively late introduction

Re: [PATCH v2 5/8] x86/hvm: Context switch MSR_PKRS

On 12/01/2023 1:10 pm, Jan Beulich wrote: > On 10.01.2023 18:18, Andrew Cooper wrote: >> +static inline void wrpkrs(uint32_t pkrs) >> +{ >> +uint32_t *this_pkrs = _cpu(pkrs); >> + >> +if ( *this_pkrs != pkrs ) >> +{ >> +*this_pkrs = pkrs; >> + >> +wrmsr_ns(MSR_PKRS,

Re: [PATCH v2 3/8] x86/iommu: iommu_igfx, iommu_qinval and iommu_snoop are VT-d specific

On 12.01.2023 16:43, Xenia Ragiadakou wrote: > On 1/12/23 13:49, Xenia Ragiadakou wrote: >> On 1/12/23 13:31, Jan Beulich wrote: >>> On 04.01.2023 09:44, Xenia Ragiadakou wrote: --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -74,9 +74,13 @@ extern enum __packed

Re: [PATCH v2 3/8] x86/iommu: iommu_igfx, iommu_qinval and iommu_snoop are VT-d specific

On 1/12/23 13:49, Xenia Ragiadakou wrote: On 1/12/23 13:31, Jan Beulich wrote: On 04.01.2023 09:44, Xenia Ragiadakou wrote: --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -82,11 +82,13 @@ static int __init cf_check parse_iommu_param(const char *s)  

[PATCH] x86/paravirt: merge activate_mm and dup_mmap callbacks

The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are sharing the same implementations in all cases: for Xen PV guests they are pinning the PGD of the new mm_struct, and for all other cases they are a NOP. So merge them to a common callback .mmu.enter_mmap (in contrast to the

Re: [PATCH v2 6/8] x86/hvm: Enable guest access to MSR_PKRS

On 12.01.2023 15:16, Andrew Cooper wrote: > On 12/01/2023 1:26 pm, Jan Beulich wrote: >> The other thing I'd like to understand (and having an answer to this >> would have been better before re-applying my R-b to this re-based >> logic) is towards the lack of feature checks here. hvm_get_reg() >>

Re: [PATCH v2 4/8] x86: Initial support for WRMSRNS

On 12.01.2023 14:58, Andrew Cooper wrote: > On 12/01/2023 12:58 pm, Jan Beulich wrote: >> Do you have any indications towards a CS prefix being the least risky >> one to use here (or in general)? > > Yes. > > Remember it's the prefix recommended for, and used by, >

Re: [PATCH] include/types: move stdlib.h-kind types to common header

On 12.01.2023 15:22, Andrew Cooper wrote: > On 12/01/2023 2:01 pm, Jan Beulich wrote: >> size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined >> on any ports Xen might gain. In particular I hope new ports can rely on >> __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by

[ovmf test] 175740: all pass - PUSHED

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

[RFC][PATCH 1/6] x86/power: De-paravirt restore_processor_state()

Since Xen PV doesn't use restore_processor_state(), and we're going to have to avoid CALL/RET until at least GS is restored, de-paravirt the easy bits. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/power/cpu.c | 24 1 file changed, 12 insertions(+), 12

[RFC][PATCH 4/6] x86/power: Sprinkle some noinstr

Ensure no compiler instrumentation sneaks in while restoring the CPU state. Specifically we can't handle CALL/RET until GS is restored. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/power/cpu.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) ---

[RFC][PATCH 2/6] x86/power: Inline write_cr[04]()

Since we can't do CALL/RET until GS is restored and CR[04] pinning is of dubious value in this code path, simply write the stored values. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/power/cpu.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/power/cpu.c +++

[RFC][PATCH 3/6] x86/callthunk: No callthunk for restore_processor_state()

From: Joan Bruguera When resuming from suspend we don't have coherent CPU state, trying to do callthunks here isn't going to work. Specifically GS isn't set yet. Signed-off-by: Joan Bruguera Signed-off-by: Peter Zijlstra (Intel) Link:

[RFC][PATCH 6/6] x86/power: Seal restore_processor_state()

Disallow indirect branches to restore_processor_state(). Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/include/asm/suspend_64.h |4 arch/x86/power/cpu.c |2 +- arch/x86/power/hibernate_asm_64.S |4 include/linux/suspend.h |4 4 files

[RFC][PATCH 5/6] PM / hibernate: Add minimal noinstr annotations

When resuming there must not be any code between swsusp_arch_suspend() and restore_processor_state() since the CPU state is ill defined at this point in time. Signed-off-by: Peter Zijlstra (Intel) --- kernel/power/hibernate.c | 30 +++--- 1 file changed, 27

[RFC][PATCH 0/6] x86: Fix suspend vs retbleed=stuff

Hi, I'm thinking these few patches should do the trick -- but I've only compiled them and looked at the resulting asm output, I've not actually ran them. Joan, could you kindly test? The last (two) patches are optional fixes and should probably not go into /urgent.

Re: [PATCH] include/types: move stdlib.h-kind types to common header

On 12/01/2023 2:01 pm, Jan Beulich wrote: > size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined > on any ports Xen might gain. In particular I hope new ports can rely on > __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler. > > Signed-off-by: Jan Beulich

Re: [PATCH v2 6/8] x86/hvm: Enable guest access to MSR_PKRS

On 12/01/2023 1:26 pm, Jan Beulich wrote: > On 10.01.2023 18:18, Andrew Cooper wrote: >> @@ -2471,6 +2477,9 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v, >> unsigned int reg) >> } >> return val; >> >> +case MSR_PKRS: >> +return (v == curr) ? rdpkrs() :

[xen-unstable-smoke test] 175741: tolerable all pass - PUSHED

flight 175741 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175741/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

[PATCH] include/types: move stdlib.h-kind types to common header

size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined on any ports Xen might gain. In particular I hope new ports can rely on __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler. Signed-off-by: Jan Beulich --- This is just to start with some hopefully

Re: [PATCH v2 4/8] x86: Initial support for WRMSRNS

On 12/01/2023 12:58 pm, Jan Beulich wrote: > On 10.01.2023 18:18, Andrew Cooper wrote: >> WRMSR Non-Serialising is an optimisation intended for cases where an MSR >> needs >> updating, but architectural serialising properties are not needed. >> >> In is anticipated that this will apply to most if

[qemu-mainline test] 175735: regressions - FAIL

flight 175735 qemu-mainline real [real] flight 175742 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/175735/ http://logs.test-lab.xenproject.org/osstest/logs/175742/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not

Re: [PATCH v2 6/8] x86/hvm: Enable guest access to MSR_PKRS

On 10.01.2023 18:18, Andrew Cooper wrote: > @@ -2471,6 +2477,9 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v, > unsigned int reg) > } > return val; > > +case MSR_PKRS: > +return (v == curr) ? rdpkrs() : msrs->pkrs; Nothing here or ... > @@ -2514,6

Re: [PATCH v2 5/8] x86/hvm: Context switch MSR_PKRS

On 10.01.2023 18:18, Andrew Cooper wrote: > +static inline void wrpkrs(uint32_t pkrs) > +{ > +uint32_t *this_pkrs = _cpu(pkrs); > + > +if ( *this_pkrs != pkrs ) > +{ > +*this_pkrs = pkrs; > + > +wrmsr_ns(MSR_PKRS, pkrs, 0); > +} > +} > + > +static inline void

Re: [PATCH v2 4/8] x86: Initial support for WRMSRNS

On 10.01.2023 18:18, Andrew Cooper wrote: > WRMSR Non-Serialising is an optimisation intended for cases where an MSR needs > updating, but architectural serialising properties are not needed. > > In is anticipated that this will apply to most if not all MSRs modified on > context switch paths. >

Re: [PATCH v2 1/8] x86/boot: Sanitise PKRU on boot

On 10.01.2023 18:18, Andrew Cooper wrote: > While the reset value of the register is 0, it might not be after kexec/etc. > If PKEY0.{WD,AD} have leaked in from an earlier context, construction of a PV > dom0 will explode. > > Sequencing wise, this must come after setting CR4.PKE, and before we

Re: [PATCH v2 5/8] x86/iommu: the code addressing CVE-2011-1898 is VT-d specific

On 1/12/23 14:01, Jan Beulich wrote: On 04.01.2023 09:44, Xenia Ragiadakou wrote: The variable untrusted_msi indicates whether the system is vulnerable to CVE-2011-1898. This vulnerablity is VT-d specific. As per the reply by Andrew to v1, this vulnerability is generic to intremap-

Re: [PATCH v2 4/8] x86/acpi: separate AMD-Vi and VT-d specific functions

On 12.01.2023 13:08, Xenia Ragiadakou wrote: > On 1/12/23 13:37, Jan Beulich wrote: >> On 04.01.2023 09:44, Xenia Ragiadakou wrote: >>> --- a/xen/arch/x86/include/asm/acpi.h >>> +++ b/xen/arch/x86/include/asm/acpi.h >>> @@ -140,8 +140,22 @@ extern u32 pmtmr_ioport; >>> extern unsigned int

Re: [PATCH v2 8/8] x86/iommu: make AMD-Vi and Intel VT-d support configurable

On 04.01.2023 09:45, Xenia Ragiadakou wrote: > Provide the user with configuration control over the IOMMU support by making > AMD_IOMMU and INTEL_IOMMU options user selectable and able to be turned off. > > However, there are cases where the IOMMU support is required, for instance for > a system

Re: [PATCH v2 6/8] x86/iommu: call pi_update_irte through an hvm_function callback

On 12.01.2023 13:16, Jan Beulich wrote: > On 04.01.2023 09:45, Xenia Ragiadakou wrote: >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -2143,6 +2143,14 @@ static bool cf_check vmx_test_pir(const struct vcpu >> *v, uint8_t vec) >> return pi_test_pir(vec,

Re: [PATCH v2 7/8] x86/dpci: move hvm_dpci_isairq_eoi() to generic HVM code

On 04.01.2023 09:45, Xenia Ragiadakou wrote: > The function hvm_dpci_isairq_eoi() has no dependencies on VT-d driver code > and can be moved from xen/drivers/passthrough/vtd/x86/hvm.c to > xen/drivers/passthrough/x86/hvm.c, along with the corresponding copyrights. > > Remove the now empty

Re: [PATCH v2 6/8] x86/iommu: call pi_update_irte through an hvm_function callback

On 04.01.2023 09:45, Xenia Ragiadakou wrote: > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -2143,6 +2143,14 @@ static bool cf_check vmx_test_pir(const struct vcpu > *v, uint8_t vec) > return pi_test_pir(vec, >arch.hvm.vmx.pi_desc); > } > > +static int cf_check

Re: [PATCH v2 4/8] x86/acpi: separate AMD-Vi and VT-d specific functions

On 1/12/23 13:37, Jan Beulich wrote: On 04.01.2023 09:44, Xenia Ragiadakou wrote: The functions acpi_dmar_init() and acpi_dmar_zap/reinstate() are VT-d specific while the function acpi_ivrs_init() is AMD-Vi specific. To eliminate dead code, they need to be guarded under CONFIG_INTEL_IOMMU and

  1   2   >