[ovmf test] 187023: all pass - PUSHED

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

[ovmf test] 187021: all pass - PUSHED

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

Re: [PATCH v1] automation: add x86_64 xilinx smoke test

Note: This test job uses the same tag 'xilinx' as the existing test 'xilinx-smoke-dom0less-arm64.sh' because there is a single gitlab runner which can run either test. Victor

[PATCH v1] automation: add x86_64 xilinx smoke test

From: Victor Lira Add a test script and related job for running x86_64 dom0 tests. Signed-off-by: Victor Lira --- Cc: Stefano Stabellini Cc: Doug Goldstein --- automation/gitlab-ci/test.yaml| 24 +++ .../scripts/xilinx-smoke-dom0-x86_64.sh | 144 ++ 2 f

[linux-linus test] 187019: regressions - FAIL

flight 187019 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/187019/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 186827 test-amd64-amd64-do

[PATCH v2] automation: upgrade Yocto to scarthgap

Upgrade Yocto to a newer version. Use ext4 as image format for testing with QEMU on ARM and ARM64 as the default is WIC and it is not available for our xen-image-minimal target. Also update the tar.bz2 filename for the rootfs. Signed-off-by: Stefano Stabellini --- all yocto tests pass: https://

Re: [PATCH] automation: upgrade Yocto to scarthgap

On Thu, 25 Jul 2024, Stefano Stabellini wrote: > Upgrade Yocto to a newer version. Use ext4 as image format for testing > with QEMU on ARM and ARM64 as the default is WIC and it is not available > for our xen-image-minimal target. > > Signed-off-by: Stefano Stabellini This patch has a couple of

[libvirt test] 187013: tolerable all pass - PUSHED

flight 187013 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/187013/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186998 test-amd64-amd64-libvirt-xsm 15 migrate-s

Re: [XEN PATCH v12 4/7] x86/domctl: Add hypercall to set the access of x86 gsi

On Fri, 26 Jul 2024, Chen, Jiqian wrote: > On 2024/7/23 06:10, Stefano Stabellini wrote: > > On Mon, 8 Jul 2024, Jiqian Chen wrote: > >> Some type of domains don't have PIRQs, like PVH, it doesn't do > >> PHYSDEVOP_map_pirq for each gsi. When passthrough a device > >> to guest base on PVH dom0, cal

[ovmf test] 187018: all pass - PUSHED

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

[linux-linus test] 187011: regressions - FAIL

flight 187011 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/187011/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 186827 test-amd64-amd64-do

[XEN PATCH v4] tools/lsevtchn: Use errno macro to handle hypercall error cases

Currently, lsevtchn aborts its event channel enumeration when it hits an event channel that is owned by Xen. lsevtchn does not distinguish between different hypercall errors, which results in lsevtchn missing potential relevant event channels with higher port numbers. Use the errno macro to disti

Re: [PATCH] x86/altcall: further refine clang workaround

On Fri Jul 26, 2024 at 5:25 PM BST, Alejandro Vallejo wrote: > On Fri Jul 26, 2024 at 4:18 PM BST, Roger Pau Monné wrote: > > On Fri, Jul 26, 2024 at 03:25:08PM +0100, Alejandro Vallejo wrote: > > > On Fri Jul 26, 2024 at 3:17 PM BST, Alejandro Vallejo wrote: > > > > On Fri Jul 26, 2024 at 9:05 AM

Re: [PATCH] x86/viridian: Clarify some viridian logging strings

On Fri Jul 26, 2024 at 4:11 PM BST, Paul Durrant wrote: > On 26/07/2024 15:52, Alejandro Vallejo wrote: > > It's sadically misleading to show an error without letters and expect > > the dmesg reader to understand it's in hex. > > That depends on who's doing the reading. > > > The patch adds a 0x pr

Re: [RFC PATCH v3] automation: add linker symbol name script

On 7/26/2024 12:44 AM, Jan Beulich wrote: + fatal "Could not find ${1} linker script. Must be run after arm/x86 build." ... why you have "arm/x86" there when the message already includes ${1}. That'll simply go stale (and unnoticed) when PPC and/or RISC-V make further progress. Actually in us

Re: [PATCH] x86/altcall: further refine clang workaround

On Fri Jul 26, 2024 at 4:18 PM BST, Roger Pau Monné wrote: > On Fri, Jul 26, 2024 at 03:25:08PM +0100, Alejandro Vallejo wrote: > > On Fri Jul 26, 2024 at 3:17 PM BST, Alejandro Vallejo wrote: > > > On Fri Jul 26, 2024 at 9:05 AM BST, Jan Beulich wrote: > > > > On 26.07.2024 09:52, Roger Pau Monné

[PATCH 14/22] x86/hvm: use a per-pCPU monitor table in shadow mode

Instead of allocating a monitor table for each vCPU when running in HVM shadow mode, use a per-pCPU monitor table, which gets the per-domain slot updated on guest context switch. Signed-off-by: Roger Pau Monné --- I've tested this manually, but XenServer builds disable shadow support, so it possi

[PATCH 21/22] 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

[PATCH 18/22] x86/mm: allow modifying per-CPU entries of remote page-tables

Add support for modifying the per-CPU page-tables entries of remote CPUs, this will be required in order to setup the page-tables of CPUs before bringing them up. A restriction is added so that remote page-tables can only be modified as long as the remote CPU is not yet online. Non functional cha

[PATCH 19/22] x86/mm: introduce a per-CPU fixmap area

Introduce the logic to manage a per-CPU fixmap area. This includes adding a new set of headers that are capable of creating mappings in the per-CPU page-table regions by making use of the map_pages_to_xen_cpu(). This per-CPU fixmap area is currently set to use one L3 slot: 1GiB of linear address

[PATCH 20/22] 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 22/22] x86/mm: zero stack on stack switch or reset

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. Signed-off-by: Rog

[PATCH 17/22] x86/mm: introduce support to populate a per-CPU page-table region

Add logic in map_pages_to_xen() and modify_xen_mappings() so that TLB flushes are only performed locally when dealing with entries in the per-CPU area of the page-tables. No functional change intended, as there are no callers added that create or modify per-CPU mappings, nor is the per-CPU area st

[PATCH 15/22] x86/idle: allow using a per-pCPU L4

Introduce support for possibly using a different L4 across the idle vCPUs. This change only introduces support for loading a per-pPCU idle L4, but even with the per-CPU idle page-table enabled it should still be a clone of idle_pg_table, hence no functional change expected. Note the idle L4 is no

[PATCH 16/22] x86/mm: introduce a per-CPU L3 table for the per-domain slot

So far L4 slot 260 has always been per-domain, in other words: all vCPUs of a domain share the same L3 entry. Currently only 3 slots are used in that L3 table, which leaves plenty of room. Introduce a per-CPU L3 that's used the the domain has Address Space Isolation enabled. Such per-CPU L3 gets

[PATCH 12/22] 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. Signed-off-by: Roger Pau Monné --- docs/misc/xen-command-line.pandoc| 15 -- xen/arch/x86/include/asm/domain.h|

[PATCH 10/22] 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/

[PATCH 08/22] x86/mm: avoid passing a domain parameter to L4 init function

In preparation for the function being called from contexts where no domain is present. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/arch/x86/include/asm/mm.h | 4 +++- xen/arch/x86/mm.c | 24 +--- xen/arch/x86/mm/hap/hap.c | 3 ++

[PATCH 04/22] x86/mm: ensure L4 idle_pg_table is not modified past boot

The idle_pg_table L4 is cloned to create all the other L4 Xen uses, and hence it shouldn't be modified once further L4 are created. Signed-off-by: Roger Pau Monné --- xen/arch/x86/mm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 6ffacab34

[PATCH 13/22] x86/hvm: use a per-pCPU monitor table in HAP mode

Instead of allocating a monitor table for each vCPU when running in HVM HAP mode, use a per-pCPU monitor table, which gets the per-domain slot updated on guest context switch. This limits the amount of memory used for HVM HAP monitor tables to the amount of active pCPUs, rather than to the number

[PATCH 00/22] 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-CPU root page-table (L4), and hence requires changes to the HVM monitor tables and shadowing the guest selected L4 on PV guests. As follow u

[PATCH 09/22] 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 06/22] x86/mm: introduce a local domain variable to write_ptbase()

This reduces the repeated accessing of v->domain. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/arch/x86/mm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index ca3d116b0e05..a792a300a866 100644 --- a/xen/

[PATCH 11/22] x86/mm: split setup of the per-domain slot on context switch

It's currently only used for XPTI. Move the code to a separate helper in preparation for it gaining more logic. While there switch to using l4e_write(): in the current context the L4 is not active when modified, but that could change. No functional change intended. Signed-off-by: Roger Pau Monn

[PATCH 07/22] x86/spec-ctrl: initialize per-domain XPTI in spec_ctrl_init_domain()

XPTI being a speculation mitigation feels better to be initialized in spec_ctrl_init_domain(). No functional change intended, although the call to spec_ctrl_init_domain() in arch_domain_create() needs to be moved ahead of pv_domain_initialise() for d->->arch.pv.xpti to be correctly set. Move it a

[PATCH 02/22] x86/mm: rename l{1,2,3,4}e_read_atomic()

There's no l{1,2,3,4}e_read() implementation, so drop the _atomic suffix from the read helpers. This allows unifying the naming with the write helpers, which are also atomic but don't have the suffix already: l{1,2,3,4}e_write(). No functional change intended. Signed-off-by: Roger Pau Monné ---

[PATCH 05/22] x86/mm: make virt_to_xen_l1e() static

There are no callers outside the translation unit where it's defined, so make the function static. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/arch/x86/include/asm/mm.h | 2 -- xen/arch/x86/mm.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) diff

[PATCH 03/22] x86/dom0: only disable SMAP for the PV dom0 build

The PVH dom0 builder doesn't switch page tables and has no need to run with SMAP disabled. Put the SMAP disabling close to the code region where it's necessary, as it then becomes obvious why switch_cr3_cr4() is required instead of write_ptbase(). Note removing SMAP from cr4_pv32_mask is not requ

[PATCH 01/22] x86/mm: drop l{1,2,3,4}e_write_atomic()

The l{1,2,3,4}e_write_atomic() and non _atomic suffixed helpers share the same implementation, so it seems pointless and possibly confusing to have both. Remove the l{1,2,3,4}e_write_atomic() helpers and switch it's user to l{1,2,3,4}e_write(), as that's also atomic. While there also remove pte_w

Re: [PATCH] x86/altcall: further refine clang workaround

On Fri, Jul 26, 2024 at 03:25:08PM +0100, Alejandro Vallejo wrote: > On Fri Jul 26, 2024 at 3:17 PM BST, Alejandro Vallejo wrote: > > On Fri Jul 26, 2024 at 9:05 AM BST, Jan Beulich wrote: > > > On 26.07.2024 09:52, Roger Pau Monné wrote: > > > > On Fri, Jul 26, 2024 at 09:36:15AM +0200, Jan Beulic

[xen-unstable test] 187010: tolerable FAIL

flight 187010 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/187010/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 8 xen-boot fail pass in 187001 test-amd64-amd64-qemuu-freebsd11

Re: [PATCH] x86/viridian: Clarify some viridian logging strings

On 26/07/2024 15:52, Alejandro Vallejo wrote: It's sadically misleading to show an error without letters and expect the dmesg reader to understand it's in hex. That depends on who's doing the reading. The patch adds a 0x prefix to all hex numbers that don't already have it. On the one instan

[PATCH v1 1/3] mm: turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig options

Let's clean that up a bit and prepare for depending on CONFIG_SPLIT_PMD_PTLOCKS in other Kconfig options. More cleanups would be reasonable (like the arch-specific "depends on" for CONFIG_SPLIT_PTE_PTLOCKS), but we'll leave that for another day. Signed-off-by: David Hildenbrand --- arch/arm/mm/

[PATCH v1 3/3] powerpc/8xx: document and enforce that split PT locks are not used

Right now, we cannot have split PT locks because 8xx does not support SMP. But for the sake of documentation *why* 8xx is fine regarding what we documented in huge_pte_lockptr(), let's just add code to enforce it at the same time as documenting it. This should also make everybody who wants to cop

[PATCH v1 2/3] mm/hugetlb: enforce that PMD PT sharing has split PMD PT locks

Sharing page tables between processes but falling back to per-MM page table locks cannot possibly work. So, let's make sure that we do have split PMD locks by adding a new Kconfig option and letting that depend on CONFIG_SPLIT_PMD_PTLOCKS. Signed-off-by: David Hildenbrand --- fs/Kconfig

[PATCH v1 0/3] mm: split PTE/PMD PT table Kconfig cleanups+clarifications

This series is a follow up to the fixes: "[PATCH v1 0/2] mm/hugetlb: fix hugetlb vs. core-mm PT locking" When working on the fixes, I wondered why 8xx is fine (-> never uses split PT locks) and how PT locking even works properly with PMD page table sharing (-> always requires split PMD PT

[PATCH] x86/viridian: Clarify some viridian logging strings

It's sadically misleading to show an error without letters and expect the dmesg reader to understand it's in hex. The patch adds a 0x prefix to all hex numbers that don't already have it. On the one instance in which a boolean is printed as an integer, print it as a decimal integer instead so it's

Re: [PATCH] x86/altcall: further refine clang workaround

On Fri Jul 26, 2024 at 3:17 PM BST, Alejandro Vallejo wrote: > On Fri Jul 26, 2024 at 9:05 AM BST, Jan Beulich wrote: > > On 26.07.2024 09:52, Roger Pau Monné wrote: > > > On Fri, Jul 26, 2024 at 09:36:15AM +0200, Jan Beulich wrote: > > >> On 26.07.2024 09:31, Roger Pau Monné wrote: > > >>> On Thu,

Re: [PATCH 07/12] libxl: Allow stubdomain to control interupts of PCI device

On Thu, Jul 25, 2024 at 04:16:37PM +0200, Marek Marczykowski-Górecki wrote: > On Thu, Jul 25, 2024 at 02:06:04PM +, Anthony PERARD wrote: > > On Thu, May 16, 2024 at 03:58:28PM +0200, Marek Marczykowski-Górecki wrote: > > > Especially allow it to control MSI/MSI-X enabling bits. This part only

Re: [PATCH] x86/altcall: further refine clang workaround

On Fri Jul 26, 2024 at 9:05 AM BST, Jan Beulich wrote: > On 26.07.2024 09:52, Roger Pau Monné wrote: > > On Fri, Jul 26, 2024 at 09:36:15AM +0200, Jan Beulich wrote: > >> On 26.07.2024 09:31, Roger Pau Monné wrote: > >>> On Thu, Jul 25, 2024 at 05:00:22PM +0200, Jan Beulich wrote: > On 25.07.2

[ovmf test] 187015: all pass - PUSHED

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

[xen-4.17-testing test] 187006: tolerable FAIL - PUSHED

flight 187006 xen-4.17-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/187006/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186819 test-amd64-amd64-xl-qemuu-win7-a

[GIT PULL] xen: branch for v6.11-rc1 take 2

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.11-rc1a-tag xen: branch for v6.11-rc1 take 2 It contains 2 fixes for issues introduced in this merge window: - one for enhanced debugging in the Xen multicall handling - a series

[xen-4.18-testing test] 187007: tolerable FAIL - PUSHED

flight 187007 xen-4.18-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/187007/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186820 test-amd64-amd64-xl-qemut-win7-a

[ovmf test] 187014: all pass - PUSHED

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

Re: [PATCH] x86/altcall: further refine clang workaround

On 26.07.2024 09:52, Roger Pau Monné wrote: > On Fri, Jul 26, 2024 at 09:36:15AM +0200, Jan Beulich wrote: >> On 26.07.2024 09:31, Roger Pau Monné wrote: >>> On Thu, Jul 25, 2024 at 05:00:22PM +0200, Jan Beulich wrote: On 25.07.2024 16:54, Roger Pau Monné wrote: > On Thu, Jul 25, 2024 at 0

Re: [PATCH] x86/altcall: further refine clang workaround

On Fri, Jul 26, 2024 at 09:36:15AM +0200, Jan Beulich wrote: > On 26.07.2024 09:31, Roger Pau Monné wrote: > > On Thu, Jul 25, 2024 at 05:00:22PM +0200, Jan Beulich wrote: > >> On 25.07.2024 16:54, Roger Pau Monné wrote: > >>> On Thu, Jul 25, 2024 at 03:18:29PM +0200, Jan Beulich wrote: > On 2

Re: [RFC PATCH v3] automation: add linker symbol name script

On 25.07.2024 21:01, victorm.l...@amd.com wrote: > From: Victor Lira > > Requested-by: Jan Beulich > Signed-off-by: Victor Lira Looks okay to me now, just that I don't see ... > --- /dev/null > +++ b/automation/eclair_analysis/linker-symbols.sh > @@ -0,0 +1,34 @@ > +#!/bin/sh > + > +# Stop im

Re: [PATCH] x86/altcall: further refine clang workaround

On 26.07.2024 09:31, Roger Pau Monné wrote: > On Thu, Jul 25, 2024 at 05:00:22PM +0200, Jan Beulich wrote: >> On 25.07.2024 16:54, Roger Pau Monné wrote: >>> On Thu, Jul 25, 2024 at 03:18:29PM +0200, Jan Beulich wrote: On 25.07.2024 12:56, Roger Pau Monne wrote: > --- a/xen/arch/x86/includ

Re: [PATCH] x86/altcall: further refine clang workaround

On Thu, Jul 25, 2024 at 05:00:22PM +0200, Jan Beulich wrote: > On 25.07.2024 16:54, Roger Pau Monné wrote: > > On Thu, Jul 25, 2024 at 03:18:29PM +0200, Jan Beulich wrote: > >> On 25.07.2024 12:56, Roger Pau Monne wrote: > >>> --- a/xen/arch/x86/include/asm/alternative.h > >>> +++ b/xen/arch/x86/in