Re: [PATCH v5 1/9] automation: upgrade Linux kernel for arm64 tests to 6.6.74

On 06/02/2025 02:08, Stefano Stabellini wrote: > > > Signed-off-by: Stefano Stabellini Any particular reason behind choosing 6.6.74 and not the latest longterm 6.6.75? In any case: Reviewed-by: Michal Orzel ~Michal

Re: [PATCH] automation: enable UBSAN for debug tests

On 06/02/2025 03:37, Stefano Stabellini wrote: > > > automation: enable UBSAN for debug tests > > Enable CONFIG_UBSAN and CONFIG_UBSAN_FATAL for the ARM64 and x86_64 > build jobs, with debug enabled, which are later used for Xen tests on > QEMU and/or real hardware. > > Signed-off-by: Stefan

[PATCH] automation: enable UBSAN for debug tests

automation: enable UBSAN for debug tests Enable CONFIG_UBSAN and CONFIG_UBSAN_FATAL for the ARM64 and x86_64 build jobs, with debug enabled, which are later used for Xen tests on QEMU and/or real hardware. Signed-off-by: Stefano Stabellini --- successful pipeline: https://gitlab.com/xen-project

Re: [PATCH v6] vpci: Add resizable bar support

On 2025/2/5 18:40, Jan Beulich wrote: > On 05.02.2025 11:31, Chen, Jiqian wrote: >> On 2025/2/5 17:58, Jan Beulich wrote: >>> On 05.02.2025 10:12, Chen, Jiqian wrote: On 2025/2/5 16:56, Roger Pau Monné wrote: > On Wed, Feb 05, 2025 at 03:42:30AM +, Chen, Jiqian wrote: >> On 2025/1/

[PATCH v5 7/9] init-dom0less: allocate xenstore page is not already allocated

We check if the xenstore page is already allocated. If yes, there is nothing to do. If no, we proceed allocating it. Signed-off-by: Stefano Stabellini --- tools/helpers/init-dom0less.c | 54 +-- 1 file changed, 51 insertions(+), 3 deletions(-) diff --git a/tools/

[PATCH v5 0/9] Guest XenStore page allocation for 11 Dom0less domUs

Hi all, The last version (v4) of this patch series [1] was fully acked and committed. However, we later discovered that it caused regressions with older Linux kernels without a fix [2], so we reverted the patch series from Xen. In the meantime, Linux backported the fix [2] to all kernels, so at p

[PATCH v5 2/9] xen/arm/static-shmem: Static-shmem should be direct-mapped for direct-mapped domains

From: Henry Wang Currently, users are allowed to map static shared memory in a non-direct-mapped way for direct-mapped domains. This can lead to clashing of guest memory spaces. Also, the current extended region finding logic only removes the host physical addresses of the static shared memory ar

[PATCH v5 3/9] xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor

From: Henry Wang There are use cases (for example using the PV driver) in Dom0less setup that require Dom0less DomUs start immediately with Dom0, but initialize XenStore later after Dom0's successful boot and call to the init-dom0less application. An error message can seen from the init-dom0less

[PATCH v5 9/9] [DO NOT COMMIT] automation: add one test using an older unpatched Linux kernel

The original patch series broke compatibility with older Linux kernels. In the meantime, Linux backported a fix that improves the general behavior and also resolve the problem. However, we still want to check Xen against possible regressions, even against old unpatches kernels. We can use the olde

[PATCH v5 5/9] docs/features/dom0less: Update the late XenStore init protocol

From: Henry Wang With the new allocation strategy of Dom0less DomUs XenStore page, update the doc of the late XenStore init protocol accordingly. Signed-off-by: Henry Wang --- docs/features/dom0less.pandoc | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/docs/fe

[PATCH v5 4/9] tools/init-dom0less: Avoid hardcoding GUEST_MAGIC_BASE

From: Henry Wang Currently the GUEST_MAGIC_BASE in the init-dom0less application is hardcoded, which will lead to failures for 1:1 direct-mapped Dom0less DomUs. Since the guest magic region allocation from init-dom0less is for XenStore, and the XenStore page is now allocated from the hypervisor,

[PATCH v5 8/9] xen/arm: introduce legacy dom0less option for xenstore allocation

The new xenstore page allocation scheme might break older unpatches Linux kernels that do not check for the Xenstore connection status before proceeding with Xenstore initialization. Introduce a dom0less configuration option to retain the older behavior, which is not compatible with 1:1 mapped gue

[PATCH v5 1/9] automation: upgrade Linux kernel for arm64 tests to 6.6.74

Signed-off-by: Stefano Stabellini --- automation/gitlab-ci/build.yaml | 4 ++-- automation/gitlab-ci/test.yaml | 2 +- .../{5.19-arm64v8.dockerfile => 6.6.74-arm64v8.dockerfile} | 5 +++-- 3 files changed, 6 insertions(+), 5 deletions(-

[PATCH v5 6/9] automation: add ping test to static-mem test

With the recent fixes, Dom0less direct mapped domains can use PV drivers. Extend the existing PV network ping tests to direct mapped guests. Signed-off-by: Stefano Stabellini --- automation/scripts/qemu-smoke-dom0less-arm64.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/automation/scr

Re: Config space access to Mediatek MT7922 doesn't work after device reset in Xen PV dom0 (regression, Linux 6.12)

On Thu, Jan 30, 2025 at 03:31:23PM -0600, Bjorn Helgaas wrote: > On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beulich wrote: > > On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote: > > > I've added logging of all config read/write to this device. Full log at > > > [1]. > > ... > > I suspect th

Re: [PATCH 01/16] x86/tsc: Add a standalone helpers for getting TSC info from CPUID.0x15

On Fri, Jan 31, 2025, Sean Christopherson wrote: > +static inline int cpuid_get_tsc_freq(unsigned int *tsc_khz, > + unsigned int *crystal_khz) > +{ > + unsigned int denominator, numerator; > + > + if (cpuid_get_tsc_info(tsc_khz, &denominator, &numerator)) A

[PATCH v2] xen/mm: Introduce per-arch pte_attr_t type for PTE flags

Xen's memory management APIs map_pages_to_xen, modify_xen_mappings, set_fixmap, ioremap_attr, and __vmap all use an unsigned int to represent architecture-dependent page table entry flags. This assumption is not well-suited for PPC/radix where some flags go past 32-bits, so introduce the pte_attr_t

Re: [PATCH v3] xen/riscv: identify specific ISA supported by cpu

Yo, On Thu, Jan 23, 2025 at 03:46:36PM +0100, Oleksii Kurochko wrote: > Supported ISA extensions are specified in the device tree within the CPU > node, using two properties: `riscv,isa-extensions` and `riscv,isa`. > > Currently, Xen does not support the `riscv,isa-extensions` property, as > all

Re: [PATCH for 4-21 v4] xen/riscv: identify specific ISA supported by cpu

On 2/4/25 12:47 PM, Jan Beulich wrote: On 04.02.2025 08:20, Oleksii Kurochko wrote: +/* + * The canonical order of ISA extension names in the ISA string is defined in + * chapter 27 of the unprivileged specification. + * + * The specification uses vague wording, such as should, when it comes to

Re: [RFC PATCH 9/9] hw/xen: Have legacy Xen backend inherit from DYNAMIC_SYS_BUS_DEVICE

On 5/2/25 00:12, Bernhard Beschow wrote: Am 4. Februar 2025 21:25:46 UTC schrieb "Philippe Mathieu-Daudé" : Hi Bernhard, On 27/1/25 10:46, Bernhard Beschow wrote: Am 25. Januar 2025 18:13:43 UTC schrieb "Philippe Mathieu-Daudé" : Because the legacy Xen backend devices can optionally be pl

Re: [PATCH v3 05/12] meson: Disallow 64-bit on 32-bit Xen emulation

On 4/2/25 22:53, Richard Henderson wrote: Require a 64-bit host binary to spawn a 64-bit guest. Signed-off-by: Richard Henderson --- meson.build | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/meson.build b/meson.build index 5a40a2a629..0ca83135e2 100644 --- a/me

Re: [PATCH v2 3/3] xen/riscv: update mfn calculation in pt_mapping_level()

On 2/4/25 3:57 PM, Jan Beulich wrote: On 03.02.2025 14:12, Oleksii Kurochko wrote: --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -55,6 +55,22 @@ #define PTE_SMALL BIT(10, UL) #define PTE_POPULATEBIT(11, UL) +/* + * In the case when modifyin

Re: [PATCH v2 for 4.20? 2/3] xen/riscv: update defintion of vmap_to_mfn()

On 2/4/25 2:56 PM, Jan Beulich wrote: On 03.02.2025 14:12, Oleksii Kurochko wrote: @@ -160,6 +158,18 @@ static inline struct page_info *virt_to_page(const void *v) pte_t * pt_walk(vaddr_t va, unsigned int *pte_level); +static inline mfn_t vmap_to_mfn_(vaddr_t va) Btw., for static funct

Re: [PATCH v2 for 4.20? 1/3] xen/riscv: implement software page table walking

On 2/4/25 2:50 PM, Jan Beulich wrote: On 03.02.2025 14:12, Oleksii Kurochko wrote: --- a/xen/arch/riscv/include/asm/mm.h +++ b/xen/arch/riscv/include/asm/mm.h @@ -156,6 +156,10 @@ static inline struct page_info *virt_to_page(const void *v) return frametable_virt_start + PFN_DOWN(va - dire

Re: [PATCH v2 3/3] pci/msi: remove pci_msi_ignore_mask

Please run git log --oneline and match the subject line capitalization style, i.e., PCI/MSI: Remove ... But it doesn't look like this actually *removes* the functionality, it just implements it differently so it can be applied more selectively. So maybe the subject should say something like "c

Re: [PATCH v2 0/3] xen: fix usage of devices behind a VMD bridge

Ping? This has been pending for 3 weeks without replies. Thanks, Roger. On Tue, Jan 14, 2025 at 11:33:10AM +0100, Roger Pau Monne wrote: > Hello, > > The following series should fix the usage of devices behind a VMD bridge > when running Linux as a Xen PV hardware domain (dom0). I've only been

Re: [PATCH v2 0/3] x86/xen: some xen_hypercall_hvm() fixes

On 05/02/2025 11:06 am, Juergen Gross wrote: > 3 fixes of the xen_hypercall_hvm() function, with the last one being > probably more a cleanup. > > Juergen Gross (3): > x86/xen: fix xen_hypercall_hvm() to not clobber %rbx > x86/xen: add FRAME_END to xen_hypercall_hvm() > x86/xen: remove unneed

Re: [PATCH for-4.20 v5] Avoid crash calling PrintErrMesg from efi_multiboot2

On Wed, Feb 5, 2025 at 10:24 AM Oleksii Kurochko wrote: > > > On 2/4/25 2:07 PM, Jan Beulich wrote: > > On 22.01.2025 11:14, Frediano Ziglio wrote: > > Although code is compiled with -fpic option data is not position > independent. This causes data pointer to become invalid if > code is not reloca

Re: [PATCH v2 0/3] x86/xen: some xen_hypercall_hvm() fixes

On 05.02.2025 12:06, Juergen Gross wrote: > 3 fixes of the xen_hypercall_hvm() function, with the last one being > probably more a cleanup. > > Juergen Gross (3): > x86/xen: fix xen_hypercall_hvm() to not clobber %rbx > x86/xen: add FRAME_END to xen_hypercall_hvm() > x86/xen: remove unneeded

[ANNOUNCE] Call for agenda items - Community Call 6th Feb 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/Hx4MN8M+usqJSpzwd0J79x3w/ *CALL LINK:* https://meet.jit.si/XenProjectCommunityCall

[PATCH v2 3/3] x86/xen: remove unneeded dummy push from xen_hypercall_hvm()

Stack alignment of the kernel in 64-bit mode is 8, not 16, so the dummy push in xen_hypercall_hvm() for aligning the stack to 16 bytes can be removed. Signed-off-by: Juergen Gross --- arch/x86/xen/xen-head.S | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/x86/xen/xen-head.S b/arch/

[PATCH v2 2/3] x86/xen: add FRAME_END to xen_hypercall_hvm()

xen_hypercall_hvm() is missing a FRAME_END at the end, add it. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502030848.htnttuo9-...@intel.com/ Fixes: b4845bb63838 ("x86/xen: add central hypercall functions") Signed-off-by: Juergen Gross --- arch/x86/xen/xen-he

[PATCH v2 1/3] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

xen_hypercall_hvm(), which is used when running as a Xen PVH guest at most only once during early boot, is clobbering %rbx. Depending on whether the caller relies on %rbx to be preserved across the call or not, this clobbering might result in an early crash of the system. This can be avoided by us

[PATCH v2 0/3] x86/xen: some xen_hypercall_hvm() fixes

3 fixes of the xen_hypercall_hvm() function, with the last one being probably more a cleanup. Juergen Gross (3): x86/xen: fix xen_hypercall_hvm() to not clobber %rbx x86/xen: add FRAME_END to xen_hypercall_hvm() x86/xen: remove unneeded dummy push from xen_hypercall_hvm() arch/x86/xen/xen-

Re: [RFC] enable UBSAN for automation tests

On Wed Feb 5, 2025 at 12:44 AM GMT, Stefano Stabellini wrote: > Hi all, > > I would like to propose to enable the UBSAN config option in our Gitlab > pipelines. The attached patch (just for testing, do not commit) enables > UBSAN on the Xen build jobs used for most of the ARM and x86 tests. The > p

Re: [PATCH v6] vpci: Add resizable bar support

On 05.02.2025 11:31, Chen, Jiqian wrote: > On 2025/2/5 17:58, Jan Beulich wrote: >> On 05.02.2025 10:12, Chen, Jiqian wrote: >>> On 2025/2/5 16:56, Roger Pau Monné wrote: On Wed, Feb 05, 2025 at 03:42:30AM +, Chen, Jiqian wrote: > On 2025/1/27 23:08, Roger Pau Monné wrote: >> On Mo

Re: [PATCH v6] vpci: Add resizable bar support

On 2025/2/5 17:58, Jan Beulich wrote: > On 05.02.2025 10:12, Chen, Jiqian wrote: >> On 2025/2/5 16:56, Roger Pau Monné wrote: >>> On Wed, Feb 05, 2025 at 03:42:30AM +, Chen, Jiqian wrote: On 2025/1/27 23:08, Roger Pau Monné wrote: > On Mon, Jan 27, 2025 at 03:52:31PM +0100, Jan Beulich

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

On 05.02.2025 11:04, Jürgen Groß wrote: > On 05.02.25 10:38, Andrew Cooper wrote: >> On 05/02/2025 9:17 am, Jürgen Groß wrote: >>> On 05.02.25 10:16, Andrew Cooper wrote: On 05/02/2025 9:10 am, Juergen Gross wrote: > xen_hypercall_hvm(), which is used when running as a Xen PVH guest at >>>

Re: [PATCH for-4.20 v5] Avoid crash calling PrintErrMesg from efi_multiboot2

On 2/4/25 2:07 PM, Jan Beulich wrote: On 22.01.2025 11:14, Frediano Ziglio wrote: Although code is compiled with -fpic option data is not position independent. This causes data pointer to become invalid if code is not relocated properly which is what happens for efi_multiboot2 which is called b

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

On 05.02.25 10:54, Jan Beulich wrote: On 05.02.2025 10:10, Juergen Gross wrote: xen_hypercall_hvm(), which is used when running as a Xen PVH guest at most only once during early boot, is clobbering %rbx. Depending on whether the caller relies on %rbx to be preserved across the call or not, this

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

On 05.02.25 10:38, Andrew Cooper wrote: On 05/02/2025 9:17 am, Jürgen Groß wrote: On 05.02.25 10:16, Andrew Cooper wrote: On 05/02/2025 9:10 am, Juergen Gross wrote: xen_hypercall_hvm(), which is used when running as a Xen PVH guest at most only once during early boot, is clobbering %rbx. Depe

Re: [PATCH v6] vpci: Add resizable bar support

On 05.02.2025 10:12, Chen, Jiqian wrote: > On 2025/2/5 16:56, Roger Pau Monné wrote: >> On Wed, Feb 05, 2025 at 03:42:30AM +, Chen, Jiqian wrote: >>> On 2025/1/27 23:08, Roger Pau Monné wrote: On Mon, Jan 27, 2025 at 03:52:31PM +0100, Jan Beulich wrote: > On 27.01.2025 15:41, Roger Pau

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

On 05.02.2025 10:10, Juergen Gross wrote: > xen_hypercall_hvm(), which is used when running as a Xen PVH guest at > most only once during early boot, is clobbering %rbx. Depending on > whether the caller relies on %rbx to be preserved across the call or > not, this clobbering might result in an ear

Re: Xen panic due to xstate mismatch

On 04.02.2025 18:35, Andrew Cooper wrote: > On 03/02/2025 8:58 am, Guillaume wrote: >> Oh cool, thanks a lot for the explanation. >> I added the "vzeroupper" and Xen crashes so it looks like the CPUID >> emulation is buggy. Also I was able to try it using a VM (same debian >> testing) running on vi

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

On 05/02/2025 9:17 am, Jürgen Groß wrote: > On 05.02.25 10:16, Andrew Cooper wrote: >> On 05/02/2025 9:10 am, Juergen Gross wrote: >>> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at >>> most only once during early boot, is clobbering %rbx. Depending on >>> whether the caller

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

On 05.02.25 10:16, Andrew Cooper wrote: On 05/02/2025 9:10 am, Juergen Gross wrote: xen_hypercall_hvm(), which is used when running as a Xen PVH guest at most only once during early boot, is clobbering %rbx. Depending on whether the caller relies on %rbx to be preserved across the call or not, t

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

On 05/02/2025 9:10 am, Juergen Gross wrote: > xen_hypercall_hvm(), which is used when running as a Xen PVH guest at > most only once during early boot, is clobbering %rbx. Depending on > whether the caller relies on %rbx to be preserved across the call or > not, this clobbering might result in an e

Re: [PATCH v6] vpci: Add resizable bar support

On 2025/2/5 16:56, Roger Pau Monné wrote: > On Wed, Feb 05, 2025 at 03:42:30AM +, Chen, Jiqian wrote: >> On 2025/1/27 23:08, Roger Pau Monné wrote: >>> On Mon, Jan 27, 2025 at 03:52:31PM +0100, Jan Beulich wrote: On 27.01.2025 15:41, Roger Pau Monné wrote: > On Mon, Jan 27, 2025 at 03:

[PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

xen_hypercall_hvm(), which is used when running as a Xen PVH guest at most only once during early boot, is clobbering %rbx. Depending on whether the caller relies on %rbx to be preserved across the call or not, this clobbering might result in an early crash of the system. This can be avoided by no

[PATCH] x86/xen: add FRAME_END to xen_hypercall_hvm()

xen_hypercall_hvm() is missing a FRAME_END at the end, add it. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502030848.htnttuo9-...@intel.com/ Fixes: b4845bb63838 ("x86/xen: add central hypercall functions") Signed-off-by: Juergen Gross --- arch/x86/xen/xen-he

Re: [PATCH v6] vpci: Add resizable bar support

On Wed, Feb 05, 2025 at 03:42:30AM +, Chen, Jiqian wrote: > On 2025/1/27 23:08, Roger Pau Monné wrote: > > On Mon, Jan 27, 2025 at 03:52:31PM +0100, Jan Beulich wrote: > >> On 27.01.2025 15:41, Roger Pau Monné wrote: > >>> On Mon, Jan 27, 2025 at 03:20:40PM +0100, Jan Beulich wrote: > On 2