Re: [PATCH] XSM/domctl: Fix permission checks on XEN_DOMCTL_createdomain

On 29.07.2024 18:26, Andrew Cooper wrote: > The XSM checks for XEN_DOMCTL_createdomain are problematic. There's a split > between xsm_domctl() called early, and flask_domain_create() called quite late > during domain construction. > > All XSM implementations except Flask have a simple IS_PRIV che

[ovmf test] 187052: all pass - PUSHED

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

Re: [PATCH v3 4/9] xen/riscv: setup fixmap mapping

On 29.07.2024 18:11, oleksii.kuroc...@gmail.com wrote: > On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote: >> On 24.07.2024 17:31, Oleksii Kurochko wrote: >>> @@ -81,6 +82,14 @@ static inline void flush_page_to_ram(unsigned >>> long mfn, bool sync_icache) >>> BUG_ON("unimplemented"); >>>  

Re: [PATCH v3 5/9] xen/riscv: introduce asm/pmap.h header

On 29.07.2024 18:22, oleksii.kuroc...@gmail.com wrote: > On Mon, 2024-07-29 at 16:29 +0200, Jan Beulich wrote: >> On 24.07.2024 17:31, Oleksii Kurochko wrote: >>> --- /dev/null >>> +++ b/xen/arch/riscv/include/asm/pmap.h >>> @@ -0,0 +1,33 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +#ifndef

Re: [PATCH v3 6/9] xen/riscv: introduce functionality to work with cpu info

On 29.07.2024 18:32, oleksii.kuroc...@gmail.com wrote: > On Mon, 2024-07-29 at 17:28 +0200, Jan Beulich wrote: >> On 24.07.2024 17:31, Oleksii Kurochko wrote: >>> +static inline unsigned int smp_processor_id(void) >>> +{ >>> +    unsigned int id; >>> + >>> +    id = get_processor_id(); >>> + >>> + 

[PATCH] bunzip2: fix rare decompression failure

The decompression code parses a huffman tree and counts the number of symbols for a given bit length. In rare cases, there may be >= 256 symbols with a given bit length, causing the unsigned char to overflow. This causes a decompression failure later when the code tries and fails to find the bit l

Re: [PATCH 2/3] xen: silence maybe-unitialized warning

On 29.07.24 21:01, Stewart Hildebrand wrote: On 7/29/24 11:03, Jürgen Groß wrote: On 29.07.24 16:24, Stewart Hildebrand wrote: When building with gcc with -finstrument-functions, optimization level -O1, CONFIG_HYPFS=y and # CONFIG_HAS_SCHED_GRANULARITY is not set, the the following build warnin

Re: [PATCH v3 7/9] xen/riscv: introduce and init SBI RFENCE extension

On Mon, 2024-07-29 at 17:52 +0200, Jan Beulich wrote: > On 24.07.2024 17:31, Oleksii Kurochko wrote: > > > > +/* > > + * Send SFENCE_VMA to a set of target HARTs. > > + * > > + * @param hart_mask mask representing set of target HARTs > > + * @param start virtual address start > > + * @param size

[linux-linus test] 187046: regressions - FAIL

flight 187046 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/187046/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827 test-arm64-arm64-xl

Re: [PATCH v3 7/9] xen/riscv: introduce and init SBI RFENCE extension

On 30.07.2024 10:44, oleksii.kuroc...@gmail.com wrote: > On Mon, 2024-07-29 at 17:52 +0200, Jan Beulich wrote: >> On 24.07.2024 17:31, Oleksii Kurochko wrote: >> >> >>> +/* >>> + * Send SFENCE_VMA to a set of target HARTs. >>> + * >>> + * @param hart_mask mask representing set of target HARTs >>> +

Re: [PATCH] bunzip2: fix rare decompression failure

On 30.07.2024 10:03, Ross Lagerwall wrote: > The decompression code parses a huffman tree and counts the number of > symbols for a given bit length. In rare cases, there may be >= 256 > symbols with a given bit length, causing the unsigned char to overflow. > This causes a decompression failure la

Re: [PATCH] bunzip2: fix rare decompression failure

On Tue, Jul 30, 2024 at 10:25 AM Jan Beulich wrote: > > On 30.07.2024 10:03, Ross Lagerwall wrote: > > The decompression code parses a huffman tree and counts the number of > > symbols for a given bit length. In rare cases, there may be >= 256 > > symbols with a given bit length, causing the unsi

Re: [XEN PATCH v5 13/17] xen: add deviations for MISRA C 2012 Dir D4.10

On 23.07.2024 10:15, Alessandro Zucchelli wrote: > From: Nicola Vetrini > > Add safe deviation for *.c files, as estabilished in past discussion. > > Signed-off-by: Maria Celeste Cesario > Signed-off-by: Simone Ballarin > Signed-off-by: Nicola Vetrini > Signed-off-by: Alessandro Zucchelli

Re: [XEN PATCH v5 13/17] xen: add deviations for MISRA C 2012 Dir D4.10

On 2024-07-30 11:45, Jan Beulich wrote: On 23.07.2024 10:15, Alessandro Zucchelli wrote: From: Nicola Vetrini Add safe deviation for *.c files, as estabilished in past discussion. Signed-off-by: Maria Celeste Cesario Signed-off-by: Simone Ballarin Signed-off-by: Nicola Vetrini Signed-o

[XEN PATCH v5 00/13] x86: make CPU virtualisation support configurable

This is another series to provide a means to render the CPU virtualisation technology support in Xen configurable. Currently, irrespectively of the target platform, both AMD-V and Intel VT-x drivers are built. The series adds three new Kconfig controls, ALT2PM, AMD_SVM and INTEL_VMX, that can be us

[XEN PATCH v5 01/13] x86: introduce AMD-V and Intel VT-x Kconfig options

From: Xenia Ragiadakou Introduce two new Kconfig options, AMD_SVM and INTEL_VMX, to allow code specific to each virtualization technology to be separated and, when not required, stripped. CONFIG_AMD_SVM will be used to enable virtual machine extensions on platforms that implement the AMD Virtuali

[XEN PATCH v5 02/13] x86/monitor: guard altp2m usage

Explicitly check whether altp2m is on for domain when getting altp2m index. If explicit call to altp2m_active() always returns false, DCE will remove call to altp2m_vcpu_idx(). p2m_get_mem_access() expects 0 as altp2m_idx parameter when altp2m not active or not supported, so 0 is a fallback value

[XEN PATCH v5 03/13] x86: introduce CONFIG_ALTP2M Kconfig option

Add new option to make altp2m code inclusion optional. Currently altp2m implemented for Intel EPT only, so option is dependant on VMX. Also the prompt itself depends on EXPERT=y, so that option is available for fine-tuning, if one want to play around with it. Use this option instead of more generi

[XEN PATCH v5 04/13] x86: introduce using_{svm,vmx}() helpers

As we now have AMD_SVM/INTEL_VMX config options for enabling/disabling these features completely in the build, we need some build-time checks to ensure that vmx/svm code can be used and things compile. Macros cpu_has_{svm,vmx} used to be doing such checks at runtime, however they do not check if SV

[XEN PATCH v5 05/13] x86/p2m: guard EPT functions with using_vmx() check

From: Xenia Ragiadakou Replace cpu_has_vmx check with using_vmx(), so that DCE would remove calls to functions ept_p2m_init() and ept_p2m_uninit() on non-VMX build. Since currently Intel EPT implementation depends on CONFIG_INTEL_VMX config option, when VMX is off these functions are unavailable.

[XEN PATCH v5 06/13] x86/traps: guard vmx specific functions with usinc_vmx() check

From: Xenia Ragiadakou Replace cpu_has_vmx check with using_vmx(), so that not only VMX support in CPU is being checked at runtime, but also at build time we ensure the availability of functions vmx_vmcs_enter() & vmx_vmcs_exit(). Also since CONFIG_VMX is checked in using_vmx and it depends on C

[XEN PATCH v5 07/13] x86/PV: guard svm specific functions with usinc_svm() check

From: Xenia Ragiadakou Replace cpu_has_svm check with using_svm(), so that not only SVM support in CPU is being checked at runtime, but also at build time we ensure the availability of functions svm_load_segs() and svm_load_segs_prefetch(). Since SVM depends on HVM, it can be used alone. Signed

[XEN PATCH v5 08/13] x86/oprofile: guard svm specific symbols with CONFIG_AMD_SVM

From: Xenia Ragiadakou The symbol svm_stgi_label is AMD-V specific so guard its usage in common code with CONFIG_AMD_SVM. Since SVM depends on HVM, it can be used alone. Also, use #ifdef instead of #if. No functional change intended. Signed-off-by: Xenia Ragiadakou Signed-off-by: Sergiy Kibri

[XEN PATCH v5 09/13] x86/vmx: guard access to cpu_has_vmx_* in common code

There're several places in common code, outside of arch/x86/hvm/vmx, where cpu_has_vmx_* get accessed without checking whether VMX supported first. These macros rely on global variables defined in vmx code, so when VMX support is disabled accesses to these variables turn into build failures. To ov

[XEN PATCH v5 10/13] x86/vpmu: guard calls to vmx/svm functions

If VMX/SVM disabled in the build, we may still want to have vPMU drivers for PV guests. Yet in such case before using VMX/SVM features and functions we have to explicitly check if they're available in the build. For this purpose (and also not to complicate conditionals) two helpers introduced -- is

[XEN PATCH v5 11/13] ioreq: do not build arch_vcpu_ioreq_completion() for non-VMX configurations

From: Xenia Ragiadakou VIO_realmode_completion is specific to vmx realmode and thus the function arch_vcpu_ioreq_completion() has actual handling work only in VMX-enabled build, as for the rest x86 and ARM build configurations it is basically a stub. Here a separate configuration option ARCH_IOR

[XEN PATCH v5 12/13] x86/vmx: replace CONFIG_HVM with CONFIG_INTEL_VMX in vmx.h

As now we got a separate config option for VMX which itself depends on CONFIG_HVM, we need to use it to provide vmx_pi_hooks_{assign,deassign} stubs for case when VMX is disabled while HVM is enabled. Signed-off-by: Sergiy Kibrik Acked-by: Jan Beulich --- changes in v5: - change kconfig option n

[XEN PATCH v5 13/13] x86/hvm: make AMD-V and Intel VT-x support configurable

From: Xenia Ragiadakou Provide the user with configuration control over the cpu virtualization support in Xen by making AMD_SVM and INTEL_VMX options user selectable. To preserve the current default behavior, both options depend on HVM and default to value of HVM. To prevent users from unknowin

Re: [PATCH 22/22] x86/mm: zero stack on stack switch or reset

On Mon, Jul 29, 2024 at 04:40:24PM +0100, Andrew Cooper wrote: > On 26/07/2024 4:22 pm, Roger Pau Monne wrote: > > 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

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

On Mon, Jul 29, 2024 at 06:51:31PM +0100, Andrew Cooper wrote: > On 29/07/2024 5:18 pm, Roger Pau Monné wrote: > > On Mon, Jul 29, 2024 at 04:52:22PM +0100, Andrew Cooper wrote: > >> On 29/07/2024 12:53 pm, Jan Beulich wrote: > >>> On 26.07.2024 17:21, Roger Pau Monne wrote: > The PVH dom0 bui

[PATCH] SUPPORT.md: split XSM from Flask

XSM is a generic framework, which in particular is also used by SILO. With this it can't really be experimental: Arm enables SILO by default. Signed-off-by: Jan Beulich --- a/SUPPORT.md +++ b/SUPPORT.md @@ -768,13 +768,20 @@ Compile time disabled for ARM by default Status, x86: Supported,

Re: [PATCH] xen: introduce xen_vring_use_dma

Hi Stefano, First off, apologies for bumping this dead thread. I came across this patch signed off by you recently https://github.com/Xilinx/linux-xlnx/commit/72cb5514953be3aa2ac00c57c9eaa100ecc67176 and was wondering if a patch replacing xen_domain() with xen_pv_domain() in vring_use_dma_api()

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

On 30/07/2024 11:55 am, Roger Pau Monné wrote: > On Mon, Jul 29, 2024 at 06:51:31PM +0100, Andrew Cooper wrote: >> On 29/07/2024 5:18 pm, Roger Pau Monné wrote: >>> On Mon, Jul 29, 2024 at 04:52:22PM +0100, Andrew Cooper wrote: On 29/07/2024 12:53 pm, Jan Beulich wrote: > On 26.07.2024 17:

[PATCH] x86: drop Xeon Phi support

Do as was decided in Lisbon. Reportedly Xen hasn't been working very well on those processors anyway. Signed-off-by: Jan Beulich --- One file I left untouched is the test harness'es predicates.c: Those tests are imo fine to retain. Plus of course the dependencies in gen-cpuid.py also want leaving

Re: [PATCH v3 4/9] xen/riscv: setup fixmap mapping

On Tue, 2024-07-30 at 09:49 +0200, Jan Beulich wrote: > On 29.07.2024 18:11, oleksii.kuroc...@gmail.com wrote: > > On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote: > > > On 24.07.2024 17:31, Oleksii Kurochko wrote: > > > > @@ -81,6 +82,14 @@ static inline void > > > > flush_page_to_ram(unsigne

Re: [PATCH] XSM/domctl: Fix permission checks on XEN_DOMCTL_createdomain

On Mon, 29 Jul 2024 12:26:51 -0400 Andrew Cooper wrote --- > The XSM checks for XEN_DOMCTL_createdomain are problematic. There's a split > between xsm_domctl() called early, and flask_domain_create() called quite > late > during domain construction. > > All XSM implementations e

Re: [PATCH] SUPPORT.md: split XSM from Flask

On Tue, 30 Jul 2024 06:57:08 -0400 Jan Beulich wrote --- > XSM is a generic framework, which in particular is also used by SILO. > With this it can't really be experimental: Arm enables SILO by default. > > Signed-off-by: Jan Beulich jbeul...@suse.com> > > --- a/SUPPORT.md > +

Re: [PATCH v3 5/9] xen/riscv: introduce asm/pmap.h header

On Tue, 2024-07-30 at 09:56 +0200, Jan Beulich wrote: > On 29.07.2024 18:22, oleksii.kuroc...@gmail.com wrote: > > On Mon, 2024-07-29 at 16:29 +0200, Jan Beulich wrote: > > > On 24.07.2024 17:31, Oleksii Kurochko wrote: > > > > --- /dev/null > > > > +++ b/xen/arch/riscv/include/asm/pmap.h > > > > @

Re: [PATCH v3 7/9] xen/riscv: introduce and init SBI RFENCE extension

On Tue, 2024-07-30 at 11:17 +0200, Jan Beulich wrote: > On 30.07.2024 10:44, oleksii.kuroc...@gmail.com wrote: > > On Mon, 2024-07-29 at 17:52 +0200, Jan Beulich wrote: > > > On 24.07.2024 17:31, Oleksii Kurochko wrote: > > > > > > > > > > +/* > > > > + * Send SFENCE_VMA to a set of target HARTs.

Re: [PATCH] x86: drop Xeon Phi support

On Tue, 2024-07-30 at 13:07 +0200, Jan Beulich wrote: > Do as was decided in Lisbon. Reportedly Xen hasn't been working very > well on those processors anyway. > > Signed-off-by: Jan Beulich > --- > One file I left untouched is the test harness'es predicates.c: Those > tests are imo fine to retai

Re: [PATCH] SUPPORT.md: split XSM from Flask

On 30.07.2024 13:37, Daniel Smith wrote: > On Tue, 30 Jul 2024 06:57:08 -0400 Jan Beulich wrote --- > > > XSM is a generic framework, which in particular is also used by SILO. > > With this it can't really be experimental: Arm enables SILO by default. > > > > Signed-off-by: Jan Beuli

Re: [PATCH v3 4/9] xen/riscv: setup fixmap mapping

On 30.07.2024 13:25, oleksii.kuroc...@gmail.com wrote: > On Tue, 2024-07-30 at 09:49 +0200, Jan Beulich wrote: >> On 29.07.2024 18:11, oleksii.kuroc...@gmail.com wrote: >>> On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote: On 24.07.2024 17:31, Oleksii Kurochko wrote: > @@ -81,6 +82,14

Re: [PATCH v3 5/9] xen/riscv: introduce asm/pmap.h header

On 30.07.2024 13:39, oleksii.kuroc...@gmail.com wrote: > On Tue, 2024-07-30 at 09:56 +0200, Jan Beulich wrote: >> On 29.07.2024 18:22, oleksii.kuroc...@gmail.com wrote: >>> On Mon, 2024-07-29 at 16:29 +0200, Jan Beulich wrote: On 24.07.2024 17:31, Oleksii Kurochko wrote: > --- /dev/null >>

[PATCH] x86/APIC: Drop APIC_BASE and use fix_to_virt()

Right now the apic_mem_*() helpers only compile because sizeof(void *) == sizeof(long long). Switch to using fix_to_virt() which is a void *type. Also adjust the two places where the APIC/IO-APIC virtual address is rendered in a printk(). No functional change. Signed-off-by: Andrew Cooper ---

Re: [PATCH v3 7/9] xen/riscv: introduce and init SBI RFENCE extension

On 30.07.2024 13:57, oleksii.kuroc...@gmail.com wrote: > On Tue, 2024-07-30 at 11:17 +0200, Jan Beulich wrote: >> On 30.07.2024 10:44, oleksii.kuroc...@gmail.com wrote: >>> On Mon, 2024-07-29 at 17:52 +0200, Jan Beulich wrote: On 24.07.2024 17:31, Oleksii Kurochko wrote: > +/* >>

Re: [PATCH] x86/APIC: Drop APIC_BASE and use fix_to_virt()

On 30.07.2024 14:17, Andrew Cooper wrote: > Right now the apic_mem_*() helpers only compile because sizeof(void *) == > sizeof(long long). Switch to using fix_to_virt() which is a void *type. > > Also adjust the two places where the APIC/IO-APIC virtual address is rendered > in a printk(). > > N

Re: [PATCH] x86/APIC: Drop APIC_BASE and use fix_to_virt()

On 30/07/2024 1:20 pm, Jan Beulich wrote: > On 30.07.2024 14:17, Andrew Cooper wrote: >> Right now the apic_mem_*() helpers only compile because sizeof(void *) == >> sizeof(long long). Switch to using fix_to_virt() which is a void *type. >> >> Also adjust the two places where the APIC/IO-APIC virt

Re: [PATCH] SUPPORT.md: split XSM from Flask

On Tue, 30 Jul 2024 08:04:09 -0400 Jan Beulich wrote --- > On 30.07.2024 13:37, Daniel Smith wrote: > > On Tue, 30 Jul 2024 06:57:08 -0400 Jan Beulich wrote --- > > > > > XSM is a generic framework, which in particular is also used by SILO. > > > With this it can't really be

Re: [PATCH] SUPPORT.md: split XSM from Flask

On 30/07/2024 11:57 am, Jan Beulich wrote: > XSM is a generic framework, which in particular is also used by SILO. > With this it can't really be experimental: Arm enables SILO by default. It's stronger than this. XSA-295 makes SILO the only security supported configuration for ARM. And since th

Re: [PATCH] SUPPORT.md: split XSM from Flask

On 30.07.2024 14:31, Daniel Smith wrote: > On Tue, 30 Jul 2024 08:04:09 -0400 Jan Beulich wrote --- > > > On 30.07.2024 13:37, Daniel Smith wrote: > > > On Tue, 30 Jul 2024 06:57:08 -0400 Jan Beulich wrote --- > > > > > > > XSM is a generic framework, which in particular is als

Re: [PATCH] SUPPORT.md: split XSM from Flask

On 30.07.2024 14:35, Andrew Cooper wrote: > On 30/07/2024 11:57 am, Jan Beulich wrote: >> XSM is a generic framework, which in particular is also used by SILO. >> With this it can't really be experimental: Arm enables SILO by default. > > It's stronger than this. > > XSA-295 makes SILO the only s

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

On Tue, Jul 30, 2024 at 12:06:45PM +0100, Andrew Cooper wrote: > On 30/07/2024 11:55 am, Roger Pau Monné wrote: > > On Mon, Jul 29, 2024 at 06:51:31PM +0100, Andrew Cooper wrote: > >> On 29/07/2024 5:18 pm, Roger Pau Monné wrote: > >>> On Mon, Jul 29, 2024 at 04:52:22PM +0100, Andrew Cooper wrote:

Re: [PATCH] SUPPORT.md: split XSM from Flask

On Tue, 30 Jul 2024 08:58:03 -0400 Jan Beulich wrote --- > On 30.07.2024 14:35, Andrew Cooper wrote: > > On 30/07/2024 11:57 am, Jan Beulich wrote: > >> XSM is a generic framework, which in particular is also used by SILO. > >> With this it can't really be experimental: Arm enables SI

Re: [XEN PATCH v12 2/7] x86/pvh: Allow (un)map_pirq when dom0 is PVH

On 08/07/2024 12:41 pm, Jiqian Chen wrote: > If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for > a passthrough device by using gsi, see qemu code > xen_pt_realize->xc_physdev_map_pirq and libxl code > pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq > will call into Xen,

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

On 26/07/2024 4:21 pm, Roger Pau Monne wrote: > 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é Acked-by: Andrew Cooper

[ovmf test] 187055: all pass - PUSHED

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

Re: [PATCH 06/22] x86/mm: introduce a local domain variable to write_ptbase()

On 26/07/2024 4:21 pm, Roger Pau Monne wrote: > This reduces the repeated accessing of v->domain. > > No functional change intended. > > Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper

Re: [PATCH v2] automation: upgrade Yocto to scarthgap

On Fri, Jul 26, 2024 at 05:19:42PM -0700, 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. > > Also update the tar.bz2 filename for the r

Re: [PATCH v2] automation: upgrade Yocto to scarthgap

On 30/07/2024 2:46 pm, Marek Marczykowski-Górecki wrote: > On Fri, Jul 26, 2024 at 05:19:42PM -0700, 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-m

Re: [PATCH v2] automation: upgrade Yocto to scarthgap

On Tue, Jul 30, 2024 at 03:01:52PM +0100, Andrew Cooper wrote: > On 30/07/2024 2:46 pm, Marek Marczykowski-Górecki wrote: > > On Fri, Jul 26, 2024 at 05:19:42PM -0700, Stefano Stabellini wrote: > >> Upgrade Yocto to a newer version. Use ext4 as image format for testing > >> with QEMU on ARM and ARM

Re: [PATCH v3 8/9] xen/riscv: page table handling

On 24.07.2024 17:31, Oleksii Kurochko wrote: > Introduces an implementation of map_pages_to_xen() which requires multiple > functions to work with page tables/entries: > - xen_pt_update() > - xen_pt_mapping_level() > - xen_pt_update_entry() > - xen_pt_next_level() > - xen_pt_check_entry() I questi

Re: [PATCH] SUPPORT.md: split XSM from Flask

On 30.07.2024 15:04, Daniel Smith wrote: > On Tue, 30 Jul 2024 08:58:03 -0400 Jan Beulich wrote --- > > > On 30.07.2024 14:35, Andrew Cooper wrote: > > > On 30/07/2024 11:57 am, Jan Beulich wrote: > > >> XSM is a generic framework, which in particular is also used by SILO. > > >> With

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

flight 187054 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/187054/ 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 1

Re: [XEN PATCH v5 02/13] x86/monitor: guard altp2m usage

On Tue, Jul 30, 2024 at 6:18 AM Sergiy Kibrik wrote: > > Explicitly check whether altp2m is on for domain when getting altp2m index. > If explicit call to altp2m_active() always returns false, DCE will remove > call to altp2m_vcpu_idx(). > > p2m_get_mem_access() expects 0 as altp2m_idx parameter w

Re: [PATCH v3 9/9] xen/riscv: introduce early_fdt_map()

On 24.07.2024 17:31, Oleksii Kurochko wrote: > Introduce function which allows to map FDT to Xen. > > Also, initialization of device_tree_flattened happens using early_fdt_map. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich with ... > @@ -64,6 +65,14 @@ void __init noreturn start_x

[PATCH v2 0/2] x86/dom0: miscellaneous fixes for PV dom0 builder

Hello, One fix to correctly restore the context on an error path, and another fix to limit SMAP disabling to PV dom0 builder. Previously part of the Address Space Isolation series, now split for ease of review. Thanks, Roger. Roger Pau Monne (2): x86/dom0: fix restoring %cr3 and the mapcache

[PATCH v2 2/2] 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. Use stac() and clac(), as that's safe to use even if events would hit in the middle of the region with SMAP disabled. Nesting stac() and clac() calls is not safe, so the stac() call is done strictly after e

[PATCH v2 1/2] x86/dom0: fix restoring %cr3 and the mapcache override on PV build error

One of the error paths in the PV dom0 builder section that runs on the guest page-tables wasn't restoring the Xen value of %cr3, neither removing the mapcache override. Fixes: 079ff2d32c3d ('libelf-loader: introduce elf_load_image') Signed-off-by: Roger Pau Monné --- xen/arch/x86/pv/dom0_build.c

[ovmf test] 187058: all pass - PUSHED

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

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

The current code in ALT_CALL_ARG() won't successfully workaround the clang code-generation issue if the arg parameter has a size that's not a power of 2. While there are no such sized parameters at the moment, improve the workaround to also be effective when such sizes are used. Instead of using a

Re: [PATCH v2] automation: upgrade Yocto to scarthgap

On Tue, 30 Jul 2024, Marek Marczykowski-Górecki wrote: > On Tue, Jul 30, 2024 at 03:01:52PM +0100, Andrew Cooper wrote: > > On 30/07/2024 2:46 pm, Marek Marczykowski-Górecki wrote: > > > On Fri, Jul 26, 2024 at 05:19:42PM -0700, Stefano Stabellini wrote: > > >> Upgrade Yocto to a newer version. Use

Re: [PATCH v2] automation: upgrade Yocto to scarthgap

On 30/07/2024 4:55 pm, Stefano Stabellini wrote: > On Tue, 30 Jul 2024, Marek Marczykowski-Górecki wrote: >> On Tue, Jul 30, 2024 at 03:01:52PM +0100, Andrew Cooper wrote: >>> On 30/07/2024 2:46 pm, Marek Marczykowski-Górecki wrote: On Fri, Jul 26, 2024 at 05:19:42PM -0700, Stefano Stabellini

[xen-4.19-testing test] 187048: regressions - FAIL

flight 187048 xen-4.19-testing real [real] flight 187060 xen-4.19-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/187048/ http://logs.test-lab.xenproject.org/osstest/logs/187060/ Regressions :-( Tests which did not succeed and are blocking, including tests which could

Re: [PATCH v2] automation: upgrade Yocto to scarthgap

On Tue, 30 Jul 2024, Andrew Cooper wrote: > On 30/07/2024 4:55 pm, Stefano Stabellini wrote: > > On Tue, 30 Jul 2024, Marek Marczykowski-Górecki wrote: > >> On Tue, Jul 30, 2024 at 03:01:52PM +0100, Andrew Cooper wrote: > >>> On 30/07/2024 2:46 pm, Marek Marczykowski-Górecki wrote: > On Fri, J

Re: [PATCH v2] automation: upgrade Yocto to scarthgap

On 30/07/2024 5:41 pm, Stefano Stabellini wrote: > On Tue, 30 Jul 2024, Andrew Cooper wrote: >> On 30/07/2024 4:55 pm, Stefano Stabellini wrote: >>> On Tue, 30 Jul 2024, Marek Marczykowski-Górecki wrote: On Tue, Jul 30, 2024 at 03:01:52PM +0100, Andrew Cooper wrote: > On 30/07/2024 2:46 pm

[libvirt test] 187050: tolerable all pass - PUSHED

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

Re: [PATCH 3/3] xen/arm: stack check instrumentation

On 7/29/24 14:36, Julien Grall wrote: > Hi Stewart, > > On 29/07/2024 15:24, Stewart Hildebrand wrote: >> Use the -finstrument-functions option to check that the stack pointer is > > Is the feature supported by both clang and GCC? Yes, I tested both. > If so, which from versions? gcc since at

Re: [PATCH 3/3] xen/arm: stack check instrumentation

On 7/29/24 16:37, Julien Grall wrote: > Hi, > > On 29/07/2024 20:40, Stewart Hildebrand wrote: >> On 7/29/24 14:50, Julien Grall wrote: >>> Hi again, >>> >>> On 29/07/2024 15:24, Stewart Hildebrand wrote: diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index aac6c599f878..b4890e

Re: [PATCH 3/3] xen/arm: stack check instrumentation

Hi, On 30/07/2024 18:50, Stewart Hildebrand wrote: On 7/29/24 14:36, Julien Grall wrote: Hi Stewart, On 29/07/2024 15:24, Stewart Hildebrand wrote: Use the -finstrument-functions option to check that the stack pointer is Is the feature supported by both clang and GCC? Yes, I tested both.

Re: [PATCH 3/3] xen/arm: stack check instrumentation

On 7/30/24 14:07, Julien Grall wrote: > Hi, > > On 30/07/2024 18:50, Stewart Hildebrand wrote: >> On 7/29/24 14:36, Julien Grall wrote: >>> Hi Stewart, >>> >>> On 29/07/2024 15:24, Stewart Hildebrand wrote: +DEFINE_PER_CPU(unsigned int, stack_check_nesting); +DEFINE_PER_CPU(unsigned char

Re: [PATCH 0/3] Stack checking on Arm

On 29/07/2024 10:37 pm, Stefano Stabellini wrote: > On Mon, 29 Jul 2024, Julien Grall wrote: >> Hi, >> >> On 29/07/2024 15:24, Stewart Hildebrand wrote: >>> This series introduces stack check instrumentation on Arm. This is >>> helpful for safety certification efforts. I'm sending this in an RFC >>

[xen-unstable test] 187051: tolerable FAIL

flight 187051 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/187051/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 10 host-ping-check-xenfail pass in 187045 Tests which did not succeed, but

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

flight 187065 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/187065/ 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 1

Re: [PATCH] xen: introduce xen_vring_use_dma

On Tue, 30 Jul 2024, Amneesh Singh wrote: > Hi Stefano, > > First off, apologies for bumping this dead thread. > > I came across this patch signed off by you recently > https://github.com/Xilinx/linux-xlnx/commit/72cb5514953be3aa2ac00c57c9eaa100ecc67176 > > and was wondering if a patch replacing

[ovmf test] 187066: all pass - PUSHED

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

[PATCH] docs/misra: add R13.2 and R18.2 to rules.rst

Add MISRA C rules 13.2 and 18.2 to rules.rst. Both rules have zero violations reported by Eclair but they have some cautions. We accept both rules and for now we'll enable scanning for them in Eclair but only violations will cause the Gitlab CI job to fail (cautions will not.) Signed-off-by: Stefa

Re: [PATCH 1/4] xen/domain: Introduce arch_init_idle_domain()

On Thu, 18 Jul 2024, Andrew Cooper wrote: > The idle domain causes a large amount of complexity in domain_create() because > of x86's need to initialise d->arch.ctxt_switch in arch_domain_create(). > > In order to address this, introduce an optional hook to perform extra > initialisation of the id

Re: [PATCH 2/4] x86/domain: Implement arch_init_idle_domain()

On Thu, 18 Jul 2024, Andrew Cooper wrote: > The idle domain needs d->arch.ctxt_switch initialised on x86. Implement the > new arch_init_idle_domain() in order to do this. > > Right now this double-initalises the ctxt_switch pointer, but it's safe and > will stop happening when domain_create() is

Re: [PATCH 3/4] xen/domain: Simpliy domain_create() now the idle domain is complete earlier

On Thu, 18 Jul 2024, Andrew Cooper wrote: > With x86 implementing arch_init_idle_domain(), there is no longer any need to > call arch_domain_create() with the idle domain. > > Have the idle domain exit early with all other system domains. Move the > static-analysis ASSERT() earlier. Then, remove

Re: [PATCH 4/4] arch/domain: Clean up the idle domain remnants in arch_domain_create()

On Thu, 18 Jul 2024, Andrew Cooper wrote: > With arch_domain_create() no longer being called with the idle domain, drop > the last remaining logic. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Stefano Stabellini but one question below > --- > CC: Jan Beulich > CC

Re: [XEN PATCH v12 2/7] x86/pvh: Allow (un)map_pirq when dom0 is PVH

Hi Andrew, On 2024/7/30 21:09, Andrew Cooper wrote: > On 08/07/2024 12:41 pm, Jiqian Chen wrote: >> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for >> a passthrough device by using gsi, see qemu code >> xen_pt_realize->xc_physdev_map_pirq and libxl code >> pci_add_dm_done->xc_physde

[linux-linus test] 187053: regressions - FAIL

flight 187053 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/187053/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827 test-arm64-arm64-xl

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

flight 187068 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/187068/ 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 1

[ovmf test] 187070: all pass - PUSHED

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

Re: [PATCH 2/3] xen/event: address violation of MISRA C Rule 13.6

On 01.07.2024 10:16, Jan Beulich wrote: > On 25.06.2024 12:14, Alessandro Zucchelli wrote: >> --- a/xen/include/xen/event.h >> +++ b/xen/include/xen/event.h >> @@ -183,13 +183,14 @@ static bool evtchn_usable(const struct evtchn *evtchn) >> /* Wait on a Xen-attached event channel. */ >> #define wa

Re: [PATCH] docs/misra: add R13.2 and R18.2 to rules.rst

On 31.07.2024 01:30, Stefano Stabellini wrote: > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -462,6 +462,15 @@ maintainers if you want to suggest a change. > - Initializer lists shall not contain persistent side effects > - > > + * - `Rule 13.2 >

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

On 30.07.2024 17:53, Roger Pau Monne wrote: > The current code in ALT_CALL_ARG() won't successfully workaround the clang > code-generation issue if the arg parameter has a size that's not a power of 2. > While there are no such sized parameters at the moment, improve the workaround > to also be eff

Re: [PATCH v2 1/2] x86/dom0: fix restoring %cr3 and the mapcache override on PV build error

On 30.07.2024 17:28, Roger Pau Monne wrote: > One of the error paths in the PV dom0 builder section that runs on the guest > page-tables wasn't restoring the Xen value of %cr3, neither removing the > mapcache override. s/neither/nor/ ? > --- a/xen/arch/x86/pv/dom0_build.c > +++ b/xen/arch/x86/pv/

Re: [PATCH v2 2/2] x86/dom0: only disable SMAP for the PV dom0 build

On 30.07.2024 17:28, Roger Pau Monne wrote: > The PVH dom0 builder doesn't switch page tables and has no need to run with > SMAP disabled. > > Use stac() and clac(), as that's safe to use even if events would hit in the > middle of the region with SMAP disabled. Nesting stac() and clac() calls is