Re: [PATCH for-4.20] public/version: soften wording for deprecated sub-ops

On Tue, Jan 07, 2025 at 09:32:05AM +0100, Jan Beulich wrote: > On 06.01.2025 23:01, Stefano Stabellini wrote: > > On Mon, 6 Jan 2025, Jan Beulich wrote: > >> On 06.01.2025 12:08, Andrew Cooper wrote: > >>> On 06/01/2025 11:04 am, Jan Beulich wrote: > These interfaces were - afaict - originally

Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()

On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote: > On 08.01.2025 09:04, Roger Pau Monné wrote: > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote: > >> On 08.01.2025 00:40, Stefano Stabellini wrote: > >>> On Tue, 7 Jan 2025, Jan Beulich wrote: > On 06.01.2025 19:48, St

Re: Xen 4.20 Development Update [December]

On 1/8/25 2:50 AM, Denis Mukhin wrote: On Tuesday, January 7th, 2025 at 9:37 AM, Oleksii Kurochko wrote: Missed to add one item to x86 about "x86/efi: Fix booting when NX is disabled". Please find some details below. On 1/7/25 6:31 PM, Oleksii Kurochko wrote: Hello everyone, This email

Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()

On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote: > On 08.01.2025 00:40, Stefano Stabellini wrote: > > On Tue, 7 Jan 2025, Jan Beulich wrote: > >> On 06.01.2025 19:48, Stefano Stabellini wrote: > >>> On Mon, 6 Jan 2025, Jan Beulich wrote: > On 04.01.2025 05:15, Denis Mukhin wrote: >

Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()

On 08.01.2025 09:04, Roger Pau Monné wrote: > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote: >> On 08.01.2025 00:40, Stefano Stabellini wrote: >>> On Tue, 7 Jan 2025, Jan Beulich wrote: On 06.01.2025 19:48, Stefano Stabellini wrote: > On Mon, 6 Jan 2025, Jan Beulich wrote: >>

Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from any domain

On 07.01.25 17:38, Jan Beulich wrote: On 07.01.2025 17:07, Jürgen Groß wrote: On 07.01.25 16:34, Jan Beulich wrote: On 07.01.2025 11:17, Juergen Gross wrote: @@ -479,8 +486,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port) */ virq = array_index_nospec(virq

Re: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub

> On 8 Jan 2025, at 07:57, Michal Orzel wrote: > > In the original patch e7a80636f16e ("xen/arm: add cache coloring support > for Xen image"), the stub was added under wrong assumption that DCE > won't remove the function call if it's not static. This assumption is > incorrect as we already re

Re: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub

> On 8 Jan 2025, at 09:01, Luca Fancellu wrote: > > > >> On 8 Jan 2025, at 07:57, Michal Orzel wrote: >> >> In the original patch e7a80636f16e ("xen/arm: add cache coloring support >> for Xen image"), the stub was added under wrong assumption that DCE >> won't remove the function call if i

Re: [PATCH for-4.20] x86/traps: Rework LER initialisation and support Zen5/Diamond Rapids

On 12/31/24 8:20 PM, Andrew Cooper wrote: AMD have always used the architectural MSRs for LER. As the first processor to support LER was the K7 (which was 32bit), we can assume it's presence unconditionally in 64bit mode. Intel are about to run out of space in Family 6 and start using 19. It

Re: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub

On 1/8/25 8:57 AM, Michal Orzel wrote: In the original patch e7a80636f16e ("xen/arm: add cache coloring support for Xen image"), the stub was added under wrong assumption that DCE won't remove the function call if it's not static. This assumption is incorrect as we already rely on DCE for cases

Re: [PATCH for-4.20] x86/traps: Rework LER initialisation and support Zen5/Diamond Rapids

On 08/01/2025 9:15 am, Oleksii Kurochko wrote: > > > On 12/31/24 8:20 PM, Andrew Cooper wrote: >> AMD have always used the architectural MSRs for LER. As the first processor >> to support LER was the K7 (which was 32bit), we can assume it's presence >> unconditionally in 64bit mode. >> >> Intel ar

[PATCH v1 8/9] xen/common: dom0less: introduce common domain-build.c

Some functions of Arm's domain_build.c could be reused by dom0less or other features connected to domain construction/build. The following functions are moved to common: - get_allocation_size(). - allocate_domheap_memory(). - guest_map_pages(). - allocate_bank_memory(). - add_hwdom_free_regions().

[PATCH v1 1/9] xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common

Unify the API for creating DomUs and checking for Dom0less mode across architectures, including Arm and RISC-V, with potential applicability for PPC. Move dom0less-build.h from the Arm-specific directory to asm-generic as these header is expected to be the same across acrhictectures with some upda

[PATCH v1 9/9] xen/common: dom0less: introduce common dom0less-build.c

Part of Arm's dom0less-build.c could be common between architectures which are using device tree files to create guest domains. Thereby move some parts of Arm's dom0less-build.c to common code with minor changes. As a part of theses changes the following changes are introduced: - Introduce make_ar

[PATCH v1 3/9] arm/static-shmem.h: drop inclusion of asm/setup.h

Nothing is dependent from asm/setup.h in asm/static-shmem.h so inclusion of asm/setup.h is droped. After this drop the following compilation error related to impicit declaration of the following functions device_tree_get_reg and map_device_irqs_to_domain, device_tree_get_u32 occur during compilati

[PATCH v1 7/9] xen/common: dom0less: introduce common kernel.c

The following functions don't have arch specific things so it is moved to common: - kernel_prboe() - kernel_load() - output_length() Functions necessary for dom0less are only moved. The following changes are done: - Swap __init and return type of kernel_decompress() function to be consistent wi

[PATCH v1 2/9] asm-generic: move parts of Arm's asm/kernel.h to asm-generic

Move the following parts to asm-generic with the following changes: - struct kernel_info: - Create arch_kernel_info for arch specific kernel information. At the moment, it contains domain_type for Arm. - Rename vpl011 to vuart to have more generic name suitable for other archs. - s/phandl

[PATCH v1 6/9] asm-generic: move some parts of Arm's domain_build.h to asm-generic header

Nothing changed. Only some functions declaration are moved to asm-generic header as they are expected to be used by common code of domain builing or dom0less. Signed-off-by: Oleksii Kurochko --- xen/arch/arm/include/asm/domain_build.h | 19 ++-- xen/include/asm-generic/domain-build.h |

[PATCH for 4.21 v1 0/9] Move parts of Arm's Dom0less to common code

Some parts of Arm's Dom0less solution could be moved to common code as they are not truly Arm-specific. Most of the code is moved as is, with only minor changes introduced to provide abstractions that hide Arm-specific details, while maintaining functional equivalence with original Arm's code. Th

[PATCH v1 5/9] asm-generic: move Arm's static-shmem.h to asm-generic

Except moving Arm's static-shmem.h to asm-generic #ifdef header guard is updated: s/__ASM_SHMEM_MEMORY_H_/__ASM_GENERIC_SHMEM_MEMORY_H__. Update arm/include/asm/Makefile to use asm-generic version of static-shmem.h for Arm. Signed-off-by: Oleksii Kurochko --- xen/arch/arm/include/asm/Makefile

[PATCH v1 4/9] asm-generic: move Arm's static-memory.h to asm-generic

Except moving Arm's static-memory.h to asm-generic #ifdef header guard is updated: s/__ASM_STATIC_MEMORY_H_/__ASM_GENERIC_STATIC_MEMORY_H__. Update arm/include/asm/Makefile to use asm-generic version of static-memory.h for Arm. Signed-off-by: Oleksii Kurochko --- xen/arch/arm/include/asm/Makefi

Re: [PATCH v3 2/2] x86: Add Support for Paging-Write Feature

On 08/01/2025 7:16 am, Jan Beulich wrote: > On 07.01.2025 18:18, Petr Beneš wrote: >> On Tue, Jan 7, 2025 at 5:46 PM Jan Beulich wrote: >>> Hmm ... Instead of you touching the bit in every one of the case blocks, >>> I was expecting you to clear the bit ahead of the switch(), accepting a >>> doubl

[PATCH v2 16/18] x86/pv: allow using a unique per-pCPU root page table (L4)

When running PV guests it's possible for the guest to use the same root page table (L4) for all vCPUs, which in turn will result in Xen also using the same root page table on all pCPUs that are running any domain vCPU. When using XPTI Xen switches to a per-CPU shadow L4 when running in guest conte

[PATCH v2 18/18] x86/mm: zero stack on context switch

With the stack mapped on a per-CPU basis there's no risk of other CPUs being able to read the stack contents, but vCPUs running on the current pCPU could read stack rubble from operations of previous vCPUs. The #DF stack is not zeroed because handling of #DF results in a panic. The contents of th

[PATCH v2 13/18] x86/spec-ctrl: introduce Address Space Isolation command line option

No functional change, as the option is not used. Introduced new so newly added functionality is keyed on the option being enabled, even if the feature is non-functional. When ASI is enabled for PV domains, printing the usage of XPTI might be omitted if it must be uniformly disabled given the usag

[PATCH v2 12/18] x86/mm: move FLUSH_ROOT_PGTBL handling before TLB flush

Move the handling of FLUSH_ROOT_PGTBL in flush_area_local() ahead of the logic that does the TLB flushing, in preparation for further changes requiring the TLB flush to be strictly done after having handled FLUSH_ROOT_PGTBL. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/

Re: [PATCH] xen/arm: ffa: fix build with clang

Hi, On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote: > Clang 16 reports: > > In file included from arch/arm/tee/ffa.c:72: > arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a > non-definition declaration [-Werror,-Wignored-attributes] > extern uint32_t __ro_after_

[PATCH v2.1 06/18] x86/pv: set/clear guest GDT mappings using {populate,destroy}_perdomain_mapping()

The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain such mappings being stashed in the domain structure, and thus such mappings being modified by merely updating the L1 entries. Switch both pv_{set,destroy}_gdt() to instead use {populate,destory}_perdomain_mapping(). Signed-

Re: [PATCH v2] xen/arm: ffa: fix build with clang

Hi Stewart, > On 8 Jan 2025, at 17:40, Stewart Hildebrand > wrote: > > Clang 16 reports: > > In file included from arch/arm/tee/ffa.c:72: > arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a > non-definition declaration [-Werror,-Wignored-attributes] > extern uint32_t __r

Re: [PATCH v4] docs: fusa: Add dom0less domain configuration requirements

Hi Ayan, This is a lot better. I just have some minor phrasing comments after. > On 8 Jan 2025, at 18:03, Ayan Kumar Halder wrote: > > From: Michal Orzel > > Add requirements for dom0less domain creation. > > Signed-off-by: Michal Orzel > Signed-off-by: Ayan Kumar Halder > --- > Changes fr

Re: [PATCH v2 1/2] x86/uaccess: rework user access speculative harden guards

On 2025-01-04 01:20, Stefano Stabellini wrote: Hi Nicola, one question below On Wed, 27 Nov 2024, Nicola Vetrini wrote: > #define AMD_OSVW_ERRATUM(osvw_id, ...) osvw_id, __VA_ARGS__, 0 > > where we're using the C99 form rather than the GNU extension, and where > hence __VA_ARGS__ would - by ex

[PATCH v4] docs: fusa: Add dom0less domain configuration requirements

From: Michal Orzel Add requirements for dom0less domain creation. Signed-off-by: Michal Orzel Signed-off-by: Ayan Kumar Halder --- Changes from - v1 - 1. As the dom0less domain creation requirements specifies the dt properties for creating domains, it has been moved to product requirements. P

[ANNOUNCE] Call for agenda items - Community Call 9th Jan 2025

Hi all, Please add your proposed agenda items below. If any action items are missing or have been resolved, please add/remove them from the sheet. https://cryptpad.fr/pad/#/2/pad/edit/TI2jaCcgSU2WnA6OeQJq-qAy/ *CALL LINK:* https://meet.jit.si/XenProjectCommunityCall

Re: [PATCH v5 00/15] Remove the directmap

Hi, Bah, I forgot to remove Wei from the CC list. Sorry, and beware the bounces when replying on patches 2 and 4... Cheers, Alejandro

Re: [PATCH v2 01/18] x86/mm: purge unneeded destroy_perdomain_mapping()

Hi, I noticed the same duplication while moving mapcache initialization code, but didn't want to touch it while doing that. Good to see these two lines gone. On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote: > The destroy_perdomain_mapping() call in the hvm_domain_initialise() fail path >

Re: [PATCH v2 02/18] x86/domain: limit window where curr_vcpu != current on context switch

This is a net gain even without ASI. Having "current" hold the previous vCPU on __context_switch() makes it _a lot_ easier to follow the lazy switch path. On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote: > On x86 Xen will perform lazy context switches to the idle vCPU, where the > previou

Re: [PATCH v3] docs: fusa: Add dom0less domain configuration requirements

On 08/01/2025 07:51, Bertrand Marquis wrote: Hi Ayan, Hi Bertrand, I just need clarifications on the two points and then I can send v4. < snip> +Domain Creation And Runtime +=== + +Kernel command line arguments +- + +`XenProd~kernel_cmd_

Re: [PATCH v3] docs: fusa: Add dom0less domain configuration requirements

Hi Ayan, > On 8 Jan 2025, at 13:54, Ayan Kumar Halder wrote: > > > On 08/01/2025 07:51, Bertrand Marquis wrote: >> Hi Ayan, > > Hi Bertrand, > > I just need clarifications on the two points and then I can send v4. > > < snip> > >>> +Domain Creation And Runtime >>> +=

[PATCH v2 1/2] ARM: ITS: implement quirks and add support for Renesas Gen4 ITS

From: Oleksandr Andrushchenko There are number of ITS implementations exist which are different from the base one which have number of functionalities defined as is "IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability, shareability and memory requirements and others. This re

[PATCH v2 0/2] Add support for Renesas R-Car Gen4

Add support for Renesas Gen4 boards such as S4[1] and V4H[2] by adding the appropriate confing option, and support for the Gen4 ITS. Tested on Renesas R-Car V4H board. [1]: https://www.renesas.com/en/products/automotive-products/automotive-system-chips-socs/r-car-s4-automotive-system-chip-soc-car

[PATCH v2 2/2] xen/arm: platform: Add support for R-Car Gen4

From: Oleksandr Andrushchenko Add Rcar Gen4 platform choice to Kconfig to select all required drivers automatically. Changelog: v1 -> v2: - Added RB from Stefano Stabellini Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Volodymyr Babchuk Signed-off-by: Mykyta Poturai Reviewed-by: Stef

Re: [PATCH for-4.20] CI: Update Fedora to 41

On Wed, Jan 08, 2025 at 12:43:16PM +, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech

[PATCH v2 15/18] x86/mm: introduce a per-vCPU mapcache when using ASI

When using a unique per-vCPU root page table the per-domain region becomes per-vCPU, and hence the mapcache is no longer shared between all vCPUs of a domain. Introduce per-vCPU mapcache structures, and modify map_domain_page() to create per-vCPU mappings when possible. Note the lock is also not

[PATCH v2 17/18] x86/mm: switch to a per-CPU mapped stack when using ASI

When using ASI the CPU stack is mapped using a range of fixmap entries in the per-CPU region. This ensures the stack is only accessible by the current CPU. Note however there's further work required in order to allocate the stack from domheap instead of xenheap, and ensure the stack is not part o

Re: [PATCH for 4.21 v1 1/1] xen/riscv: identify specific ISA supported by cpu

On 23.12.2024 13:55, Oleksii Kurochko wrote: > --- /dev/null > +++ b/xen/arch/riscv/cpufeature.c > @@ -0,0 +1,466 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Taken for Linux kernel v6.12-rc3 and modified by > + * Oleksii Kurochko : > + * > + * - Drop unconditional setting of {RISC

[PATCH v5 15/15] xen/arm64: Allow the admin to enable/disable the directmap

From: Julien Grall Implement the same command line option as x86 to enable/disable the directmap. By default this is kept enabled. Also modify setup_directmap_mappings() to populate the L0 entries related to the directmap area. Signed-off-by: Julien Grall Signed-off-by: Elias El Yandouzi Sign

[PATCH v5 06/15] xen/x86: Add support for the PMAP

From: Julien Grall PMAP will be used in a follow-up patch to bootstrap map domain page infrastructure -- we need some way to map pages to setup the mapcache without a direct map. The functions pmap_{map, unmap} open code {set, clear}_fixmap to break the loop. Signed-off-by: Julien Grall Signed

[PATCH v5 03/15] x86/pv: Rewrite how building PV dom0 handles domheap mappings

From: Hongyan Xia Building a PV dom0 is allocating from the domheap but uses it like the xenheap. Use the pages as they should be. Signed-off-by: Hongyan Xia Signed-off-by: Julien Grall Signed-off-by: Elias El Yandouzi Signed-off-by: Alejandro Vallejo --- v4->v5: * Bugfix: Don't map l4star

[PATCH v5 04/15] x86: Initialize mapcache for PV, HVM, and idle domains

From: Wei Liu To support the transition away from the direct map, the mapcache will now be used by HVM and idle domains as well. This patch lifts the `mapcache` to the arch level and moves its initialization to `arch_domain_create()`. For the idle domain to utilize the mapcache, this patch also

[PATCH v5 02/15] x86/pv: Use copy_domain_page() to manage domheap pages during initrd relocation

From: Wei Liu Replace the manual copying logic with a call to `copy_domain_page()` while relocating intird which map and unmap pages accordingly. Signed-off-by: Wei Liu Signed-off-by: Wei Wang Signed-off-by: Julien Grall Signed-off-by: Elias El Yandouzi Signed-off-by: Alejandro Vallejo ---

[PATCH v5 01/15] x86: Create per-domain mapping for guest_root_pt

From: Hongyan Xia This patch introduces a per-domain mapping for the `guest_root_pt` in PV guests as part of the effort to remove the direct map in Xen. For the time being, the `root_pgt` is not mapped or unmapped, as it remains a Xenheap page. This will be addressed in subsequent patches. Sign

[PATCH v5 08/15] xen/page_alloc: Add a path for xenheap when there is no direct map

From: Hongyan Xia When there is not an always-mapped direct map, xenheap allocations need to be mapped and unmapped on-demand. Signed-off-by: Hongyan Xia Signed-off-by: Julien Grall Signed-off-by: Elias El Yandouzi Signed-off-by: Alejandro Vallejo --- v4->v5: * Remove stray comma in printk

[PATCH v5 11/15] x86/setup: Do not create valid mappings when directmap=no

From: Hongyan Xia Create empty mappings in the second e820 pass. Also, destroy existing direct map mappings created in the first pass. To make xenheap pages visible in guests, it is necessary to create empty L3 tables in the direct map even when directmap=no, since guest cr3s copy idle domain's

[PATCH v5 14/15] xen/arm64: Implement a mapcache for arm64

From: Julien Grall At the moment, on arm64, map_domain_page() is implemented using virt_to_mfn(). Therefore it is relying on the directmap. In a follow-up patch, we will allow the admin to remove the directmap. Therefore we want to implement a mapcache. Thanksfully there is already one for arm3

[PATCH v5 05/15] x86: Add a boot option to enable and disable the direct map

From: Hongyan Xia This is added as a Kconfig option as well as a boot command line option. While being generic, the Kconfig option is only usable for x86 at the moment. Note that there remains some users of the directmap at this point. The option is introduced now as it will be needed in follow-

[PATCH v5 07/15] x86/domain_page: Remove the fast paths when mfn is not in the directmap

From: Hongyan Xia When mfn is not in direct map, never use mfn_to_virt for any mappings. We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with arch_mfns_in_direct_map(mfn, 1) because these two are equivalent. The extra comparison in arch_mfns_in_direct_map() looks different but b

[PATCH v5 13/15] xen/arm32: Hardwire zeroeth_table_offset to 0 on ARM_32

Include arm32 in 7c72147baa22("xen/arm: Restrict zeroeth_table_offset for ARM_64"). Otherwise `va` overflows on shift in DECLARE_OFFSETS(). Fixes: 7c72147baa22("xen/arm: Restrict zeroeth_table_offset for ARM_64") Signed-off-by: Alejandro Vallejo --- xen/arch/arm/include/asm/lpae.h | 2 +- 1 file

[PATCH v5 10/15] xen/page_alloc: vmap heap nodes when they are outside the direct map

From: Hongyan Xia When we do not have a direct map, archs_mfn_in_direct_map() will always return false, thus init_node_heap() will allocate xenheap pages from an existing node for the metadata of a new node. This means that the metadata of a new node is in a different node, slowing down heap allo

[PATCH v5 12/15] xen/arm64: mm: Use per-pCPU page-tables

From: Julien Grall At the moment, on Arm64, every pCPU is sharing the same page-tables. In a follow-up patch, we will allow the possibility to remove the direct map and therefore it will be necessary to have a mapcache. While we have plenty of spare virtual address space to reserve part for eac

[PATCH v5 09/15] x86/setup: Leave early boot slightly earlier

From: Hongyan Xia When we do not have a direct map, memory for metadata of heap nodes in init_node_heap() is allocated from xenheap, which needs to be mapped and unmapped on demand. However, we cannot just take memory from the boot allocator to create the PTEs while we are passing memory to the h

Re: [PATCH] xen/arm: ffa: fix build with clang

Hi, > On 8 Jan 2025, at 16:45, Alejandro Vallejo > wrote: > > Hi, > > On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote: >> Clang 16 reports: >> >> In file included from arch/arm/tee/ffa.c:72: >> arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a >> non-definit

Re: [PATCH] xen/arm: ffa: fix build with clang

On 1/8/25 11:34, Bertrand Marquis wrote: > Hi, > >> On 8 Jan 2025, at 16:45, Alejandro Vallejo >> wrote: >> >> Hi, >> >> On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote: >>> Clang 16 reports: >>> >>> In file included from arch/arm/tee/ffa.c:72: >>> arch/arm/tee/ffa_private.h:329:17:

[PATCH v2] xen/arm: ffa: fix build with clang

Clang 16 reports: In file included from arch/arm/tee/ffa.c:72: arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a non-definition declaration [-Werror,-Wignored-attributes] extern uint32_t __ro_after_init ffa_fw_version; ^ The variable ffa_fw_version is only u

Re: [PATCH 3/3] virtio-gpu: add a new command to get p2pdma_distance

On Sat, Dec 07, 2024 at 06:55:40PM +0800, Julia Zhang wrote: > diff --git a/include/standard-headers/linux/virtio_gpu.h > b/include/standard-headers/linux/virtio_gpu.h > index 6459fdb9fb..2e55dcc2fe 100644 > --- a/include/standard-headers/linux/virtio_gpu.h > +++ b/include/standard-headers/linux/v

[PATCH v2 00/18] x86: adventures in Address Space Isolation

Hello, The aim of this series is to introduce the functionality required to create linear mappings visible to a single pCPU. Doing so requires having a per-vCPU root page-table (L4), and hence requires shadowing the guest selected L4 on PV guests. As follow ups (and partially to ensure the per-C

[PATCH v2 09/18] x86/mm: simplify create_perdomain_mapping() interface

There are no longer any callers of create_perdomain_mapping() that request a reference to the used L1 tables, and hence the only difference between them is whether the caller wants the region to be populated, or just the paging structures to be allocated. Simplify the arguments to create_perdomain

[PATCH v2 11/18] x86/pv: untie issuing FLUSH_ROOT_PGTBL from XPTI

The current logic gates issuing flush TLB requests with the FLUSH_ROOT_PGTBL flag to XPTI being enabled. In preparation for FLUSH_ROOT_PGTBL also being needed when not using XPTI, untie it from the xpti domain boolean and instead introduce a new flush_root_pt field. No functional change intended,

[PATCH v2 01/18] x86/mm: purge unneeded destroy_perdomain_mapping()

The destroy_perdomain_mapping() call in the hvm_domain_initialise() fail path is useless. destroy_perdomain_mapping() called with nr == 0 is effectively a no op, as there are not entries torn down. Remove the call, as arch_domain_create() already calls free_perdomain_mappings() on failure. There

[PATCH v2 04/18] x86/pv: introduce function to populate perdomain area and use it to map Xen GDT

The current code to update the Xen part of the GDT when running a PV guest relies on caching the direct map address of all the L1 tables used to map the GDT and LDT, so that entries can be modified. Introduce a new function that populates the per-domain region, either using the recursive linear ma

[PATCH v2 10/18] x86/mm: switch {create,destroy}_perdomain_mapping() domain parameter to vCPU

In preparation for the per-domain area being per-vCPU. This requires moving some of the {create,destroy}_perdomain_mapping() calls to the domain initialization and tear down paths into vCPU initialization and tear down. Signed-off-by: Roger Pau Monné --- xen/arch/x86/domain.c | 12 +

[PATCH v2 06/18] x86/pv: set/clear guest GDT mappings using {populate,destroy}_perdomain_mapping()

The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain such mappings being stashed in the domain structure, and thus such mappings being modified by merely updating the L1 entries. Switch both pv_{set,destroy}_gdt() to instead use {populate,destory}_perdomain_mapping(). Note th

[PATCH v2 08/18] x86/pv: remove stashing of GDT/LDT L1 page-tables

There are no remaining callers of pv_gdt_ptes() or pv_ldt_ptes() that use the stashed L1 page-tables in the domain structure. As such, the helpers and the fields can now be removed. No functional change intended, as the removed logic is not used. Signed-off-by: Roger Pau Monné --- xen/arch/x86

[PATCH v2 02/18] x86/domain: limit window where curr_vcpu != current on context switch

On x86 Xen will perform lazy context switches to the idle vCPU, where the previously running vCPU context is not overwritten, and only current is updated to point to the idle vCPU. The state is then disjunct between current and curr_vcpu: current points to the idle vCPU, while curr_vcpu points to

[PATCH v2 03/18] x86/mm: introduce helper to detect per-domain L1 entries that need freeing

L1 present entries that require the underlying page to be freed have the _PAGE_AVAIL0 bit set, introduce a helper to unify the checking logic into a single place. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/arch/x86/mm.c | 14 -- 1 file changed, 8 insertion

[PATCH v2 07/18] x86/pv: update guest LDT mappings using the linear entries

The pv_map_ldt_shadow_page() and pv_destroy_ldt() functions rely on the L1 table(s) that contain such mappings being stashed in the domain structure, and thus such mappings being modified by merely updating the require L1 entries. Switch pv_map_ldt_shadow_page() to unconditionally use the linear r

[PATCH v2 14/18] x86/mm: introduce per-vCPU L3 page-table

Such table is to be used in the per-domain slot when running with Address Space Isolation enabled for the domain. Signed-off-by: Roger Pau Monné --- xen/arch/x86/include/asm/domain.h | 3 +++ xen/arch/x86/include/asm/mm.h | 2 +- xen/arch/x86/mm.c | 45 +

[PATCH v2 05/18] x86/mm: switch destroy_perdomain_mapping() parameter from domain to vCPU

In preparation for the per-domain area being populated with per-vCPU mappings change the parameter of destroy_perdomain_mapping() to be a vCPU instead of a domain, and also update the function logic to allow manipulation of per-domain mappings using the linear page table mappings. Signed-off-by: R

[PATCH] xen/arm: ffa: fix build with clang

Clang 16 reports: In file included from arch/arm/tee/ffa.c:72: arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a non-definition declaration [-Werror,-Wignored-attributes] extern uint32_t __ro_after_init ffa_fw_version; ^ Remove the attribute from the header

[PATCH v5 00/15] Remove the directmap

Hi, I picked v4 of this series and run it through XenRT extensively, fixing crashes and errors as I hit them. Likewise, I've run it through Gitlab, fixing various CI failures. I listed all changes per patch. I fixed ARM to the extent that "Gitlab is happy when CONFIG_ONDEMAND_DIRECTMAP=y", but I d

Re: [PATCH] xen/arm: ffa: fix build with clang

Hi Stewart, Thanks a lot for the finding and the fix :-) > On 8 Jan 2025, at 16:23, Stewart Hildebrand > wrote: > > Clang 16 reports: > > In file included from arch/arm/tee/ffa.c:72: > arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a > non-definition declaration [-Werr

Re: [XEN RFC PATCH v4 0/5] IOMMU subsystem redesign and PV-IOMMU interface

On Mon, Nov 04, 2024 at 02:28:38PM +, Teddy Astie wrote: > This work has been presented at Xen Summit 2024 during the > IOMMU paravirtualization and Xen IOMMU subsystem rework > design session. > > Operating systems may want to have access to a IOMMU in order to do DMA > protection or implem

Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()

On Wed, 8 Jan 2025, Denis Mukhin wrote: > On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné > wrote: > > On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote: > > > On 08.01.2025 09:04, Roger Pau Monné wrote: > > > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote: >

Re: [PATCH v2 06/15] x86/hyperlaunch: introduce the domain builder

On 2024-12-26 11:57, Daniel P. Smith wrote: Introduce the domain builder which is capable of consuming a device tree as the first boot module. If it finds a device tree as the first boot module, it will set its type to BOOTMOD_FDT. This change only detects the boot module and continues to boot wi

[PATCH v4 3/6] x86: re-work memcpy()

Move the function to its own assembly file. Having it in C just for the entire body to be an asm() isn't really helpful. Then have two flavors: A "basic" version using qword steps for the bulk of the operation, and an ERMS version for modern hardware, to be substituted in via alternatives patching.

[PATCH v4 2/6] x86: re-work memset()

Move the function to its own assembly file. Having it in C just for the entire body to be an asm() isn't really helpful. Then have two flavors: A "basic" version using qword steps for the bulk of the operation, and an ERMS version for modern hardware, to be substituted in via alternatives patching.

[PATCH v4 5/6] x86: introduce "hot" and "cold" page clearing functions

The present clear_page_sse2() is useful in case a page isn't going to get touched again soon, or if we want to limit churn on the caches. Amend it by alternatively using CLZERO, which has been found to be quite a bit faster on Zen2 hardware at least. Note that to use CLZERO, we need to know the cac

[PATCH v4 6/6] mm: allow page scrubbing routine(s) to be arch controlled

Especially when dealing with large amounts of memory, memset() may not be very efficient; this can be bad enough that even for debug builds a custom function is warranted. We additionally want to distinguish "hot" and "cold" cases (with, as initial heuristic, "hot" being for any allocations a domai

Re: [PATCH v2 1/2] tools/libs: remove dead code

Hi Ariel, On Tue, Dec 24, 2024 at 08:13:54PM +0100, Ariel Otilibili wrote: > Default switch cases skip these steps; these instructions are never reached. The "default" case might skip these statements, but the intention behind those statements is to make sure that every other cases also skip thes

Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from any domain

On 08.01.2025 10:02, Jürgen Groß wrote: > On 07.01.25 17:38, Jan Beulich wrote: >> On 07.01.2025 17:07, Jürgen Groß wrote: >>> On 07.01.25 16:34, Jan Beulich wrote: On 07.01.2025 11:17, Juergen Gross wrote: > @@ -479,8 +486,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, > evtchn

Re: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub

Hi Michal > On 8 Jan 2025, at 08:57, Michal Orzel wrote: > > In the original patch e7a80636f16e ("xen/arm: add cache coloring support > for Xen image"), the stub was added under wrong assumption that DCE > won't remove the function call if it's not static. This assumption is > incorrect as we al

[PATCH v4 4/6] x86: control memset() and memcpy() inlining

Stop the compiler from inlining non-trivial memset() and memcpy() (for memset() see e.g. map_vcpu_info() or kimage_load_segments() for examples). This way we even keep the compiler from using REP STOSQ / REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is available). With gcc10 this yie

[PATCH v4 0/6] x86: memcpy() / memset() (non-)ERMS flavors plus fallout

While the performance varies quite a bit on older (pre-ERMS) and newer (ERMS) hardware, so far we've been going with just a single flavor of these two functions, and oddly enough with ones not consistent with one another. Using plain memcpy() / memset() on MMIO (video frame buffer) is generally oka

[PATCH v4 1/6] x86: suppress ERMS for internal use when MISC_ENABLE.FAST_STRING is clear

Before we start actually adjusting behavior when ERMS is available, follow Linux commit 161ec53c702c ("x86, mem, intel: Initialize Enhanced REP MOVSB/STOSB") and zap the CPUID-derived feature flag when the MSR bit is clear. Don't extend the artificial clearing to guest view, though: Guests can take

Re: Bug: Hyperlinks in generated documentation may point to the wrong architecture

On 30/12/2024 8:56 pm, Maximilian Engelhardt wrote: > Hello, > > during working on packaging Xen in Debian I noticed the documentation becomes > non-reproducible as hyperlinks may point to the wrong architecture. > > Here an example as diff showing the problem: > > /usr/share/doc/xen/html/hypercal

[PATCH for-4.20] CI: Update Fedora to 41

Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Stefano Stabellini CC: Michal Orzel CC: Doug Goldstein CC: Oleksii Kurochko CC: Marek Marczykowski-Górecki https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1616092048 --- .../fedora/{40-x86_64.dockerfile => 41-x86_64.dock

Re: [PATCH for-4.20] CI: Update Fedora to 41

On Wed, 8 Jan 2025, Anthony PERARD wrote: > On Wed, Jan 08, 2025 at 12:43:16PM +, Andrew Cooper wrote: > > Signed-off-by: Andrew Cooper > > Reviewed-by: Anthony PERARD Reviewed-by: Stefano Stabellini

Re: [PATCH] xen/arm: ffa: fix build with clang

On 08/01/2025 3:45 pm, Alejandro Vallejo wrote: > Hi, > > On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote: >> It appears the variable ffa_fw_version is only used in ffa.c. Was there >> any rationale for exporting the symbol in 2f9f240a5e87 ("xen/arm: ffa: >> Fine granular call support")

Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()

On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné wrote: > > > On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote: > > > On 08.01.2025 09:04, Roger Pau Monné wrote: > > > > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote: > > > > > > > On 08.01.2025 00:40,