Re: [PATCH v4 2/6] xen: define ACPI and DT device info sections macros

On 26.09.2024 18:54, Oleksii Kurochko wrote: > Introduce macros to define device information sections based on > the configuration of ACPI or device tree support. These sections > are required for common code of device initialization and getting > an information about a device. > > These macros ar

[ovmf test] 187871: all pass - PUSHED

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

Re: [PATCH v4 1/6] xen: introduce SIMPLE_DECL_SECTION

On 26.09.2024 18:54, Oleksii Kurochko wrote: > Introduce SIMPLE_DECL_SECTION to cover the case when > an architecture wants to declare a section without specifying > of load address for the section. > > Update x86/xen.lds.S to use SIMPLE_DECL_SECTION. > > Signed-off-by: Oleksii Kurochko Acked-b

Re: [PATCH v4 5/6] xen/riscv: add section for device information in linker script

On 26.09.2024 18:54, Oleksii Kurochko wrote: > Introduce a new `.dev.info` section in the RISC-V linker script to > handle device-specific information. This section is required by > common code (common/device.c: device_init(), device_get_class() ). > This section is aligned to `POINTER_ALIGN`, with

Re: [PATCH v2] drivers/video: Convert source files to UTF-8

On 26.09.2024 18:03, Frediano Ziglio wrote: > On Thu, Sep 26, 2024 at 3:46 PM Jan Beulich wrote: >> >> On 26.09.2024 15:48, Frediano Ziglio wrote: >>> --- a/xen/drivers/video/font_8x14.c >>> +++ b/xen/drivers/video/font_8x14.c >>> @@ -2059,7 +2059,7 @@ static const unsigned char fontdata_8x14[FONT

Re: [PATCH v4 6/6] xen/ppc: mm-radix: Allocate all paging structures at runtime

On 27.09.2024 00:14, Shawn Anastasio wrote: > On 4/24/24 9:46 AM, Jan Beulich wrote: >> On 12.04.2024 05:55, Shawn Anastasio wrote: >>> +/* >>> + * Identity map all pages we've allocated for paging structures. This >>> act >>> + * itself will allocate more pages, so continue until we'v

[qemu-mainline test] 187863: regressions - FAIL

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

[libvirt test] 187865: tolerable all pass - PUSHED

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

Re: [PATCH 4/5] x86/xen: Avoid relocatable quantities in Xen ELF notes

On Fri, 27 Sept 2024 at 03:47, Jason Andryuk wrote: > > On 2024-09-26 06:41, Ard Biesheuvel wrote: > > From: Ard Biesheuvel > > > > Xen puts virtual and physical addresses into ELF notes that are treated > > by the linker as relocatable by default. Doing so is not only pointless, > > given that t

[PATCH v3] drivers/video: Convert source files to UTF-8

Most of the tools nowadays assume this encoding. These files do not specify any encoding so convert them to the default. Signed-off-by: Frediano Ziglio --- xen/drivers/video/font_8x14.c | 256 +- xen/drivers/video/font_8x16.c | 256 +---

[xen-unstable test] 187861: tolerable FAIL - PUSHED

flight 187861 xen-unstable real [real] flight 187868 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/187861/ http://logs.test-lab.xenproject.org/osstest/logs/187868/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armh

Re: [PATCH 4/5] x86/xen: Avoid relocatable quantities in Xen ELF notes

On 2024-09-26 06:41, Ard Biesheuvel wrote: From: Ard Biesheuvel Xen puts virtual and physical addresses into ELF notes that are treated by the linker as relocatable by default. Doing so is not only pointless, given that the ELF notes are only intended for consumption by Xen before the kernel bo

Re: [PATCH] Update deprecated SPDX license identifiers

On Thu, 26 Sep 2024, Frediano Ziglio wrote: > As specified in LICENSES/GPL-2.0: > - GPL-2.0 -> GPL-2.0-only; > - GPL-2.0+ -> GPL-2.0-or-later. > > Signed-off-by: Frediano Ziglio Reviewed-by: Stefano Stabellini > --- > CODING_STYLE | 2 +- > xen/arch/arm/altern

[PATCH v5 0/3] Early Boot Allocation on Power

Hello all, This series enables the Xen boot time allocator on Power by parsing the available memory regions from the firmware-provided device tree. Thanks to Oleksii's work on my patches to move ARM's bootfdt code to common, v5 is much smaller. One new patch is included to fix some newly-broken b

[PATCH v5 1/3] xen/device-tree: Let DT reserve map entries overlap reserved-memory

Commit 53dc37829c31 ("xen/arm: Add DT reserve map regions to bootinfo.reserved_mem") changes the way reserve map regions are tracked, and as a result broke bootfdt's ability to handle device trees in which the reserve map and the `reserved-memory` node contain the same entries as each other, as is

[PATCH v5 2/3] xen/ppc: Enable bootfdt and boot allocator

Enable usage of bootfdt for populating the boot info struct from the firmware-provided device tree. Also enable the Xen boot page allocator. Additionally, modify bootfdt.c's boot_fdt_info() to tolerate the scenario in which the FDT overlaps a reserved memory region, as is the case on PPC when boo

[PATCH v5 3/3] xen/ppc: mm-radix: Allocate all paging structures at runtime

In the initial mm-radix implementation, the in-memory partition and process tables required to configure the MMU, as well as the page tables themselves were all allocated statically since the boot allocator was not yet available. Now that it is, allocate these structures at runtime and bump the si

Re: [PATCH v1 3/6] xen/arm: create dom0less virtio-pci DT node

On Tue, Sep 24, 2024 at 04:55:15PM -0700, Stefano Stabellini wrote: > On Tue, 24 Sep 2024, Edgar E. Iglesias wrote: > > From: Stewart Hildebrand > > > > When virtio-pci is specified in the dom0less domU properties, create a > > virtio-pci node in the guest's device tree. Set up an mmio handler wi

Re: [PATCH v4 6/6] xen/ppc: mm-radix: Allocate all paging structures at runtime

Hi Jan, I'm revisiting this series and wanted to follow up on your comments. On 4/24/24 9:46 AM, Jan Beulich wrote: > On 12.04.2024 05:55, Shawn Anastasio wrote: >> +/* >> + * A thin wrapper for alloc_boot_pages that keeps track of the maximum and >> + * minimum mfns that have been allocated. Thi

Re: [RFC PATCH 02/28] Documentation: Bump minimum GCC version to 8.1

On Wed, Sep 25, 2024 at 5:10 PM Ard Biesheuvel wrote: > > Documentation/admin-guide/README.rst | 2 +- > Documentation/process/changes.rst| 2 +- This should update scripts/min-tool-version.sh too. With that: Acked-by: Miguel Ojeda As Arnd says, the cleanups can be done afterwards. Cheers

[ovmf test] 187866: all pass - PUSHED

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

Re: [PATCH v4 05/44] x86/boot: introduce struct boot_module

On 9/3/24 19:29, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h index e785ed1c5982..844262495962 100644 --- a/xen/arch/x86/include/asm/bootinfo.h +++ b/xen/arch/x86/include/asm/bootinfo.h

Re: [PATCH 3/5] x86/pvh: Omit needless clearing of phys_base

On 2024-09-26 06:41, Ard Biesheuvel wrote: From: Ard Biesheuvel Since commit d9ec1158056b ("x86/boot/64: Use RIP_REL_REF() to assign 'phys_base'") phys_base is assigned directly rather than added to, so it is no longer necessary to clear it after use. Signed-off-by: Ard Biesheuvel Revi

Re: [PATCH 2/5] x86/pvh: Use correct size value in GDT descriptor

On 2024-09-26 06:41, Ard Biesheuvel wrote: From: Ard Biesheuvel The size field in a GDT descriptor is offset by 1, so subtract 1 from the calculated range. Signed-off-by: Ard Biesheuvel I guess with s/size/limit/ per Andrew. Reviewed-by: Jason Andryuk Tested-by: Jason Andryuk Thanks, Ja

Re: [PATCH 1/5] x86/pvh: Call C code via the kernel virtual mapping

On 2024-09-26 06:55, Ard Biesheuvel wrote: On Thu, 26 Sept 2024 at 12:41, Ard Biesheuvel wrote: From: Ard Biesheuvel Calling C code via a different mapping than it was linked at is problematic, because the compiler assumes that RIP-relative and absolute symbol references are interchangeable.

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

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

[linux-linus test] 187860: tolerable FAIL - PUSHED

flight 187860 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/187860/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187848 test-amd64-amd64-xl-qemuu-win7-amd64

Re: [PATCH] x86/PV: simplify (and thus correct) guest accessor functions

On 02/09/2024 4:09 pm, Jan Beulich wrote: > On 02.09.2024 16:13, Andrew Cooper wrote: >> On 02/09/2024 1:28 pm, Jan Beulich wrote: >>> Taking a fault on a non-byte-granular insn means that the "number of >>> bytes not handled" return value would need extra care in calculating, if >>> we want caller

[PATCH v4 6/6] xen/common: move device initialization code to common code

Remove the device initialization code from `xen/arch/arm/device.c` and move it to the common code to avoid duplication and make it accessible for both ARM and other architectures. device_get_class(), device_init(), _sdevice[] and _edevice[] are wrapped by "#ifdef CONFIG_HAS_DEVICE_TREE" for the cas

Re: [PATCH v4 13/44] x86/boot: update struct boot_module on module relocation

On 9/3/24 19:48, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 021c5699f86c..27517d24b2ea 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1408,8 +1408,10 @@ void asmlinkage __init noreturn __sta

Re: [PATCH v4 08/44] x86/boot: convert setup.c mod refs to early_mod

On 9/4/24 02:47, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: To allow a slow conversion of x86 over to struct boot_module, start with replacing all references to struct mod to the early_mod element of struct boot_module. These serves twofold, first to allow the incremental tra

Re: [PATCH v4 09/44] x86/boot: split bootstrap_map_addr() out of bootstrap_map()

On 9/4/24 06:47, Andrew Cooper wrote: On 04/09/2024 7:49 am, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: From: Andrew Cooper Using an interface based on addresses directly, not modules. No functional change. Okay, a mechanical transformation. But what's the goal? Its us

[PATCH v4 0/6] Move {acpi_}device_init() and device_get_class() to common code

The {acpi_}device_init() and device_get_class() functions are identical across Arm and RISC-V, and they are likely to remain the same for other architectures like PPC. Since there is no architecture-specific logic within these functions, they are good candidates to be moved to the common codebase.

[PATCH v4 3/6] xen/arm: use {DT,ACPI}_DEV_INFO for device info sections

Refactor arm/xen.lds.S by replacing the inline definitions for device info sections with the newly introduced {DT,ACPI}_DEV_INFO macros from xen/xen.lds.h. Signed-off-by: Oleksii Kurochko --- Changes in V4: - use newly refactored ACPI_DEV_INFO and DT_DEV_INFO --- Changes in V3: - use refactored

Re: [PATCH v4 09/44] x86/boot: split bootstrap_map_addr() out of bootstrap_map()

On 9/4/24 02:49, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: From: Andrew Cooper Using an interface based on addresses directly, not modules. No functional change. Okay, a mechanical transformation. But what's the goal? I would defer to Andy's reply. --- a/xen/arch/x8

Re: [PATCH v3 3/5] xen/livepatch: do Xen build-id check earlier

On Thu, Sep 26, 2024 at 05:11:19PM +0100, Ross Lagerwall wrote: > On Thu, Sep 26, 2024 at 11:21 AM Roger Pau Monne wrote: > > > > The check against the expected Xen build ID should be done ahead of > > attempting > > to apply the alternatives contained in the livepatch. > > > > If the CPUID in th

[PATCH v4 5/6] xen/riscv: add section for device information in linker script

Introduce a new `.dev.info` section in the RISC-V linker script to handle device-specific information. This section is required by common code (common/device.c: device_init(), device_get_class() ). This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice` marking the start and end

[PATCH v4 2/6] xen: define ACPI and DT device info sections macros

Introduce macros to define device information sections based on the configuration of ACPI or device tree support. These sections are required for common code of device initialization and getting an information about a device. These macros are expected to be used across different architectures (Arm

[PATCH v3] xen: move per-cpu area management into common code

Centralize per-cpu area management to reduce code duplication and enhance maintainability across architectures. The per-cpu area management code, which is largely common among architectures, is moved to a shared implementation in xen/common/percpu.c. This change includes: * Remove percpu.c from t

[PATCH v4 4/6] xen/ppc: add section for device information in linker script

Introduce a new `.dev.info` section in the PPC linker script to handle device-specific information. This section is required by common code (common/device.c: device_init(), device_get_class() ). This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice` marking the start and end of

[PATCH v4 1/6] xen: introduce SIMPLE_DECL_SECTION

Introduce SIMPLE_DECL_SECTION to cover the case when an architecture wants to declare a section without specifying of load address for the section. Update x86/xen.lds.S to use SIMPLE_DECL_SECTION. Signed-off-by: Oleksii Kurochko --- Changes in V4: - new patch --- xen/arch/x86/xen.lds.S| 6

Re: [PATCH v3 2/5] xen/livepatch: simplify and unify logic in prepare_payload()

On Thu, Sep 26, 2024 at 11:21 AM Roger Pau Monne wrote: > > The following sections: .note.gnu.build-id, .livepatch.xen_depends and > .livepatch.depends are mandatory and ensured to be present by > check_special_sections() before prepare_payload() is called. > > Simplify the logic in prepare_payloa

Re: [PATCH v4 08/44] x86/boot: convert setup.c mod refs to early_mod

On 9/3/24 19:50, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: @@ -1379,6 +1379,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) if ( xen_phys_start ) { +int idx = boot_info->nr_mods; unsigned int, but I'd be tempted to name i

Re: [PATCH v4 07/44] x86/boot: move headroom to boot modules

On 9/4/24 02:45, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: The purpose of struct boot_module is to encapsulate the state of boot modules. Doing locates boot module state with its respective boot module, reduces I'm struggling with the start of this sentence. Yep, grammar

Re: [PATCH v4 04/44] x86/boot: move mmap info to boot info

On 9/3/24 19:18, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: Transition the memory map info to be held in struct boot_info. No functional change intended. Signed-off-by: Daniel P. Smith --- xen/arch/x86/include/asm/bootinfo.h | 5 + xen/arch/x86/setup.c

Re: [PATCH v4 06/44] x86/boot: convert consider_modules to struct boot_module

On 9/4/24 06:41, Andrew Cooper wrote: On 04/09/2024 7:40 am, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: @@ -1447,7 +1447,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) { /* Don't overlap with modules. */ end = con

Re: [PATCH v4 07/44] x86/boot: move headroom to boot modules

On 9/3/24 19:40, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h index 844262495962..3e0e36df096b 100644 --- a/xen/arch/x86/include/asm/bootinfo.h +++ b/xen/arch/x86/include/asm/bootinfo.h

Re: [PATCH v3 3/5] xen/livepatch: do Xen build-id check earlier

On Thu, Sep 26, 2024 at 11:21 AM Roger Pau Monne wrote: > > The check against the expected Xen build ID should be done ahead of attempting > to apply the alternatives contained in the livepatch. > > If the CPUID in the alternatives patching data is out of the scope of the > running Xen featureset

Re: [PATCH v4 06/44] x86/boot: convert consider_modules to struct boot_module

On 9/4/24 02:40, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -632,7 +632,7 @@ static void __init noinline move_xen(void) #undef BOOTSTRAP_MAP_LIMIT static uint64_t __init consider_modules( -uint64_t s, uint64

Re: [PATCH v4 05/44] x86/boot: introduce struct boot_module

On 9/4/24 02:33, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: @@ -303,6 +308,14 @@ static void __init multiboot_to_bootinfo(multiboot_info_t *mbi) info.mmap_length = mbi->mmap_length; } +info.mods = boot_mods; + +for ( i=0; i < info.nr_mods; i++ ) +

Re: [PATCH v2] drivers/video: Convert source files to UTF-8

On Thu, Sep 26, 2024 at 3:46 PM Jan Beulich wrote: > > On 26.09.2024 15:48, Frediano Ziglio wrote: > > --- a/xen/drivers/video/font_8x14.c > > +++ b/xen/drivers/video/font_8x14.c > > @@ -2059,7 +2059,7 @@ static const unsigned char fontdata_8x14[FONTDATAMAX] > > = { > > 0x00, /* */

Re: [PATCH v4 04/44] x86/boot: move mmap info to boot info

On 9/4/24 02:26, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: --- a/xen/arch/x86/include/asm/bootinfo.h +++ b/xen/arch/x86/include/asm/bootinfo.h @@ -8,11 +8,16 @@ #ifndef __XEN_X86_BOOTINFO_H__ #define __XEN_X86_BOOTINFO_H__ +#include + struct boot_info { unsi

Re: [PATCH v4 03/44] x86/boot: move cmdline to boot info

On 9/3/24 19:04, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: Transition Xen's command line to being held in struct boot_info. No functional change intended. Signed-off-by: Daniel P. Smith Acked-by: Andrew Cooper Thank you. diff --git a/xen/arch/x86/setup.c b/xen

Re: [PATCH v3 1/5] xen/livepatch: drop load_addr Elf section field

On Thu, Sep 26, 2024 at 11:21 AM Roger Pau Monne wrote: > > The Elf loading logic will initially use the `data` section field to stash a > pointer to the temporary loaded data (from the buffer allocated in > livepatch_upload(), which is later relocated and the new pointer stashed in > `load_addr`.

Re: [PATCH v4 02/44] x86/boot: move boot loader name to boot info

On 9/3/24 18:41, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: Transition the incoming boot loader name to be held in struct boot_info. No functional change intended. Signed-off-by: Daniel P. Smith --- xen/arch/x86/include/asm/bootinfo.h | 2 ++ xen/arch/x86/setup.c

Re: [PATCH v4 01/44] x86/boot: move x86 boot module counting into a new boot_info struct

V/r, Daniel P. Smith Apertus Solutions, LLC On 9/4/24 02:31, Jan Beulich wrote: On 30.08.2024 23:46, Daniel P. Smith wrote: @@ -276,7 +277,16 @@ static int __init cf_check parse_acpi_param(const char *s) custom_param("acpi", parse_acpi_param); static const module_t *__initdata initial

Re: [PATCH v4 01/44] x86/boot: move x86 boot module counting into a new boot_info struct

On 9/3/24 18:35, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index eee20bb1753c..dd94ee2e736b 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1034,9 +1044,10 @@ void asmlinkage __init noreturn __sta

Re: [PATCH v2] drivers/video: Convert source files to UTF-8

On 26.09.2024 15:48, Frediano Ziglio wrote: > --- a/xen/drivers/video/font_8x14.c > +++ b/xen/drivers/video/font_8x14.c > @@ -2059,7 +2059,7 @@ static const unsigned char fontdata_8x14[FONTDATAMAX] = > { > 0x00, /* */ > 0x00, /* */ > > -/* 128 0x80 'Ÿˆ */ > +/

Re: [PATCH v5 4/7] x86: introduce x86_seg_sys

On 04/09/2024 1:29 pm, Jan Beulich wrote: > To represent the USER-MSR bitmap access, a new segment type needs > introducing, behaving like x86_seg_none in terms of address treatment, > but behaving like a system segment for page walk purposes (implicit > supervisor-mode access). > > Signed-off-by:

Re: [PATCH v4 01/44] x86/boot: move x86 boot module counting into a new boot_info struct

On 9/3/24 18:24, Andrew Cooper wrote: On 30/08/2024 10:46 pm, Daniel P. Smith wrote: From: Christopher Clark An initial step towards a non-multiboot internal representation of boot modules for common code, starting with x86 setup and converting the fields that are accessed for the startup calc

Re: [PATCH 2/5] x86/pvh: Use correct size value in GDT descriptor

On 26/09/2024 11:41 am, Ard Biesheuvel wrote: > From: Ard Biesheuvel > > The size field in a GDT descriptor is offset by 1, so subtract 1 from > the calculated range. > > Signed-off-by: Ard Biesheuvel I realise this is probably nitpicking, but the GDT descriptor has a limit field, which is (inte

Re: [PATCH v4] Avoid crash calling PrintErrMesg from efi_multiboot2

On 26.09.2024 16:11, Andrew Cooper wrote: > On 26/09/2024 2:26 pm, Marek Marczykowski-Górecki wrote: >> On Mon, Aug 19, 2024 at 03:29:52PM +0100, Frediano Ziglio wrote: >>> Although code is compiled with -fpic option data is not position >>> independent. This causes data pointer to become invalid i

Re: [PATCH v4 01/44] x86/boot: move x86 boot module counting into a new boot_info struct

On 9/2/24 09:47, Alejandro Vallejo wrote: I haven't read the entire series yet, but here's my .02 so far On Fri Aug 30, 2024 at 10:46 PM BST, Daniel P. Smith wrote: From: Christopher Clark An initial step towards a non-multiboot internal representation of boot modules for common code, startin

Re: [PATCH v4] Avoid crash calling PrintErrMesg from efi_multiboot2

On 26/09/2024 2:26 pm, Marek Marczykowski-Górecki wrote: > On Mon, Aug 19, 2024 at 03:29:52PM +0100, 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 wh

[PATCH] drivers/video: Convert source files to UTF-8

Most of the tools nowadays assume this encoding. These files do not specify any encoding so convert them to the default. Signed-off-by: Frediano Ziglio --- xen/drivers/video/font_8x14.c | 256 +- xen/drivers/video/font_8x16.c | 256 +---

[libvirt test] 187853: tolerable all pass - PUSHED

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

Re: [PATCH v4] Avoid crash calling PrintErrMesg from efi_multiboot2

On Mon, Aug 19, 2024 at 03:29:52PM +0100, 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 by multiboot e

[PATCH v2] drivers/video: Convert source files to UTF-8

Most of the tools nowadays assume this encoding. These files do not specify any encoding so convert them to the default. Signed-off-by: Frediano Ziglio --- xen/drivers/video/font_8x14.c | 256 +- xen/drivers/video/font_8x16.c | 256 +---

[qemu-mainline test] 187852: regressions - FAIL

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

Re: [PATCH] drivers/video: Convert source files to UTF-8

On Thu, Sep 26, 2024 at 2:27 PM Frediano Ziglio wrote: > > Most of the tools nowadays assume this encoding. > These files do not specify any encoding so convert them to the default. > > Signed-off-by: Frediano Ziglio Please ignore, the tools did a pretty bad job formatting and sending the email

Re: [RFC PATCH 27/28] x86/kernel: Switch to PIE linking for the core kernel

On Wed, 25 Sept 2024 at 22:25, Vegard Nossum wrote: > > > On 25/09/2024 17:01, Ard Biesheuvel wrote: > > From: Ard Biesheuvel > > > > Build the kernel as a Position Independent Executable (PIE). This > > results in more efficient relocation processing for the virtual > > displacement of the kerne

Re: [XEN PATCH 0/2] blkif: Fix discard req align requirement and various typos

On Thu, Sep 26, 2024 at 12:53:49PM +, Anthony PERARD wrote: > Patch series available in this git branch: > https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git > br.blkif-wording-fix-v1 That was fast, thanks: Reviewed-by: Roger Pau Monné Regards, Roger.

Re: [XEN PATCH 0/2] blkif: Fix discard req align requirement and various typos

On 26.09.24 14:53, Anthony PERARD wrote: Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.blkif-wording-fix-v1 Cheers, Anthony PERARD (2): blkif: Fix alignment description for discard request blkif: Fix a couple of typos xe

Re: [XEN PATCH 2/2] blkif: Fix a couple of typos

On Thu, Sep 26, 2024 at 1:54 PM Anthony PERARD wrote: > > Those where fixed in OVMF's copy. (And one of them fixed in QEMU's > copy but later discarded by an update.) > > Signed-off-by: Anthony PERARD > --- > xen/include/public/io/blkif.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(

[XEN PATCH 1/2] blkif: Fix alignment description for discard request

The discard feature have an other xenstore node to described the size of the blocks than can be discarded, "discard-granularity", which default to "sector-size" when absent as noted in the properties and in note 4. So discard request should be aligned on this value. Fixes: 221f2748e8da ("blkif: re

[XEN PATCH 0/2] blkif: Fix discard req align requirement and various typos

Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.blkif-wording-fix-v1 Cheers, Anthony PERARD (2): blkif: Fix alignment description for discard request blkif: Fix a couple of typos xen/include/public/io/blkif.h | 6 +++--- 1 file

[XEN PATCH 2/2] blkif: Fix a couple of typos

Those where fixed in OVMF's copy. (And one of them fixed in QEMU's copy but later discarded by an update.) Signed-off-by: Anthony PERARD --- xen/include/public/io/blkif.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io

Re: [PATCH v3 1/5] xen/livepatch: drop load_addr Elf section field

On 26/09/2024 12:14, Roger Pau Monne wrote: > > > The Elf loading logic will initially use the `data` section field to stash a > pointer to the temporary loaded data (from the buffer allocated in > livepatch_upload(), which is later relocated and the new pointer stashed in > `load_addr`. > >

Re: [RFC PATCH] arm: introduce kconfig options to disable hypercalls

On 26/09/2024 10:58 am, Sergiy Kibrik wrote: > diff --git a/xen/common/Makefile b/xen/common/Makefile > index fc52e0857d..ea0557aee5 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -64,10 +64,14 @@ obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 > unxz unlzma lzo unlzo

Re: [PATCH v3 4/5] x86/alternatives: do not BUG during apply

On Thu, Sep 26, 2024 at 12:09:05PM +0100, Andrew Cooper wrote: > On 26/09/2024 11:14 am, Roger Pau Monne wrote: > > diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c > > index 7824053c9d33..990b7c600932 100644 > > --- a/xen/arch/x86/alternative.c > > +++ b/xen/arch/x86/alternativ

Re: [PATCH v3 1/5] xen/livepatch: drop load_addr Elf section field

On Thu, Sep 26, 2024 at 12:04:06PM +0100, Andrew Cooper wrote: > On 26/09/2024 11:14 am, Roger Pau Monne wrote: > > The Elf loading logic will initially use the `data` section field to stash a > > pointer to the temporary loaded data (from the buffer allocated in > > livepatch_upload(), which is la

Re: [PATCH v3 4/5] x86/alternatives: do not BUG during apply

On 26/09/2024 11:14 am, Roger Pau Monne wrote: > diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c > index 7824053c9d33..990b7c600932 100644 > --- a/xen/arch/x86/alternative.c > +++ b/xen/arch/x86/alternative.c > @@ -198,9 +198,29 @@ static void init_or_livepatch _apply_alternati

Re: [PATCH v3] blkif: reconcile protocol specification with in-use implementations

On Thu, Sep 26, 2024 at 09:46:43AM +, Anthony PERARD wrote: > On Thu, Sep 12, 2024 at 11:57:29AM +0200, Roger Pau Monne wrote: > > /* > > * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD > > * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request) > >

Re: [PATCH v3 3/5] xen/livepatch: do Xen build-id check earlier

On 26/09/2024 11:14 am, Roger Pau Monne wrote: > The check against the expected Xen build ID should be done ahead of attempting > to apply the alternatives contained in the livepatch. > > If the CPUID in the alternatives patching data is out of the scope of the > running Xen featureset the BUG() in

Re: [PATCH v3 1/5] xen/livepatch: drop load_addr Elf section field

On 26/09/2024 11:14 am, Roger Pau Monne wrote: > The Elf loading logic will initially use the `data` section field to stash a > pointer to the temporary loaded data (from the buffer allocated in > livepatch_upload(), which is later relocated and the new pointer stashed in > `load_addr`. > > Remove

Re: [PATCH 1/5] x86/pvh: Call C code via the kernel virtual mapping

On Thu, 26 Sept 2024 at 12:41, Ard Biesheuvel wrote: > > From: Ard Biesheuvel > > Calling C code via a different mapping than it was linked at is > problematic, because the compiler assumes that RIP-relative and absolute > symbol references are interchangeable. GCC in particular may use > RIP-rel

[PATCH 2/5] x86/pvh: Use correct size value in GDT descriptor

From: Ard Biesheuvel The size field in a GDT descriptor is offset by 1, so subtract 1 from the calculated range. Signed-off-by: Ard Biesheuvel --- arch/x86/platform/pvh/head.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/p

Re: [PATCH v6 0/3] x86/boot: Reduce assembly code

On 26.09.2024 11:21, Frediano Ziglio wrote: > This series came from part of the work of removing duplications between > boot code and rewriting part of code from assembly to C. > First patch rework BIOS/PVH paths to reuse some code. > Second patch rewrites EFI code in pure C. > > Changes since v1,

[PATCH 4/5] x86/xen: Avoid relocatable quantities in Xen ELF notes

From: Ard Biesheuvel Xen puts virtual and physical addresses into ELF notes that are treated by the linker as relocatable by default. Doing so is not only pointless, given that the ELF notes are only intended for consumption by Xen before the kernel boots. It is also a KASLR leak, given that the

[PATCH 5/5] x86/pvh: Avoid absolute symbol references in .head.text

From: Ard Biesheuvel The .head.text section contains code that may execute from a different address than it was linked at. This is fragile, given that the x86 ABI can refer to global symbols via absolute or relative references, and the toolchain assumes that these are interchangeable, which they

[PATCH 3/5] x86/pvh: Omit needless clearing of phys_base

From: Ard Biesheuvel Since commit d9ec1158056b ("x86/boot/64: Use RIP_REL_REF() to assign 'phys_base'") phys_base is assigned directly rather than added to, so it is no longer necessary to clear it after use. Signed-off-by: Ard Biesheuvel --- arch/x86/platform/pvh/head.S | 7 --- 1 fil

[PATCH 1/5] x86/pvh: Call C code via the kernel virtual mapping

From: Ard Biesheuvel Calling C code via a different mapping than it was linked at is problematic, because the compiler assumes that RIP-relative and absolute symbol references are interchangeable. GCC in particular may use RIP-relative per-CPU variable references even when not using -fpic. So ca

[PATCH 0/5] x86/xen: Drop absolute references from startup code

From: Ard Biesheuvel This series was broken out of the series I sent yesterday [0], after Jason pointed out that my Xen startup code changes conflict with his changes to make the PVH startup code position independent. Jason's work reduces the delta of my changes, and given that my other series w

Re: [PATCH v4 2/4] x86/boot: Refactor BIOS/PVH start

On 26.09.2024 11:24, Frediano Ziglio wrote: > On Thu, Sep 26, 2024 at 7:50 AM Jan Beulich wrote: >> >> On 25.09.2024 21:33, Andrew Cooper wrote: >>> On 25/09/2024 7:00 am, Frediano Ziglio wrote: @@ -449,62 +458,40 @@ __pvh_start: mov %ecx, %es mov %ecx, %ss

Re: [PATCH v3 1/5] xen: define ACPI and DT device info sections macros

On 26.09.2024 11:15, oleksii.kuroc...@gmail.com wrote: > On Thu, 2024-09-26 at 08:23 +0200, Jan Beulich wrote: >> On 25.09.2024 18:08, oleksii.kuroc...@gmail.com wrote: >>> On Wed, 2024-09-25 at 10:36 +0200, Jan Beulich wrote: PPC's desire to use DECL_SECTION() can certainly be covered by

[PATCH v3 5/5] x86/alternative: build time check feature is in range

Ensure at build time the feature(s) used for the alternative blocks are in range of the featureset. No functional change intended, as all current usages are correct. Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper --- Changes since v2: - s/__stringify/STR/. Changes since v1: - New

[XEN PATCH v6] x86/intel: optional build of PSR support

Xen's implementation of PSR only supports Intel CPUs right now, hence it can be made dependant on CONFIG_INTEL build option. Since platform implementation is not limited to single vendor, intermediate option CONFIG_X86_PSR introduced, which selected by CONFIG_INTEL. When !X86_PSR then PSR-related

Re: [POLL] Interest in next Xen Project meetup (Cambridge)

Hi Peng, There are no current plans to record this as these types of meetups are best in person. However, If there's enough interest, we can consider adding a virtual or recorded element where possible. Kelly Choi Community Manager Xen Project On Thu, Sep 26, 2024 at 1

[PATCH 1/2] include: update Xen public headers io/blkif.h

Signed-off-by: Anthony PERARD --- include/hw/xen/interface/io/blkif.h | 52 + 1 file changed, 39 insertions(+), 13 deletions(-) diff --git a/include/hw/xen/interface/io/blkif.h b/include/hw/xen/interface/io/blkif.h index 22f1eef0c0..9b00d633d3 100644 --- a/include/hw

[PATCH 0/2] Xen: Update sector-size handling in block backend

The specification have been clarified regarding what "sector" is in Xen PV block protocol by Xen commit 221f2748e8da ("blkif: reconcile protocol specification with in-use implementations") and "feature-large-sector-size" have been removed. https://xenbits.xenproject.org/gitweb/?p=xen.git;a=commit;

  1   2   >