[ovmf test] 187464: regressions - FAIL

flight 187464 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/187464/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 187463 build-i386

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

On 03.09.2024 08:20, Chen, Jiqian wrote: > On 2024/9/3 14:09, Jan Beulich wrote: >> On 03.09.2024 06:01, Chen, Jiqian wrote: >>> On 2024/8/20 15:07, Jan Beulich wrote: On 20.08.2024 08:12, Chen, Jiqian wrote: > On 2024/8/19 17:08, Jan Beulich wrote: >> On 16.08.2024 13:08, Jiqian Chen

Re: [PATCH v2] x86/boot: Use fastcall for 32bit code

On 02.09.2024 18:54, Andrew Cooper wrote: > This is marginally more efficient, but is mostly to get rid of the use of > stdcall in cmdline.c and reloc.c > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > v2: > * Fixed up to work properly. > > I'm tempted t

Re: [PATCH v2 1/2] x86/time: split CMOS time fetching into wrapper

On 30.08.2024 11:52, Roger Pau Monne wrote: > @@ -1285,33 +1270,56 @@ static unsigned long get_cmos_time(void) > } while ( (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) && >t2 < MILLISECS(3) ); > > -__get_cmos_time(&rtc); > +__get_cmos_time(rtc); > >

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

On 2024/9/3 14:09, Jan Beulich wrote: > On 03.09.2024 06:01, Chen, Jiqian wrote: >> On 2024/8/20 15:07, Jan Beulich wrote: >>> On 20.08.2024 08:12, Chen, Jiqian wrote: On 2024/8/19 17:08, Jan Beulich wrote: > On 16.08.2024 13:08, Jiqian Chen wrote: >> If run Xen with PVH dom0 and hvm d

Re: [XEN PATCH v3 1/3] libxl: Fix nul-termination of the return value of libxl_xen_console_read_line()

On 02.09.2024 18:38, Javi Merino wrote: > When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)" > call in main_dmesg(). ASAN reports a heap buffer overflow: an > off-by-one access to cr->buffer. > > The readconsole sysctl copies up to count characters into the buffer, > but it does

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

On 03.09.2024 06:01, Chen, Jiqian wrote: > On 2024/8/20 15:07, Jan Beulich wrote: >> On 20.08.2024 08:12, Chen, Jiqian wrote: >>> On 2024/8/19 17:08, Jan Beulich wrote: On 16.08.2024 13:08, Jiqian Chen wrote: > If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for > a passthro

[ovmf test] 187463: all pass - PUSHED

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

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

On 2024/8/20 15:07, Jan Beulich wrote: > On 20.08.2024 08:12, Chen, Jiqian wrote: >> On 2024/8/19 17:08, Jan Beulich wrote: >>> On 16.08.2024 13:08, 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_

[ovmf test] 187462: all pass - PUSHED

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

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

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

[ovmf test] 187460: all pass - PUSHED

flight 187460 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/187460/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 82c5cacd134d64ea0d0f4dabdbbde38017acb70d baseline version: ovmf eaf78e43f206f8587bdf6

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

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

flight 187459 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/187459/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf eaf78e43f206f8587bdf6c0f78c0f021192d5859 baseline version: ovmf 96b90e150c2f107c64a82

Re: [PATCH v3 1/3] docs: Introduce Fusa Requirement and define maintainers

Hi Ayan Sorry for delay - I was ill and then off for the whole August Just for the record: Acked-by: Artem Mygaiev Best regards, -- Artem Mygaiev From: Ayan Kumar Halder Sent: Tuesday, August 6, 2024 19:31 To: sstabell...@kernel.org ; bertrand.marq...@a

[PATCH v6 7/9] xen/riscv: introduce and initialize SBI RFENCE extension

Introduce functions to work with the SBI RFENCE extension for issuing various fence operations to remote CPUs. Add the sbi_init() function along with auxiliary functions and macro definitions for proper initialization and checking the availability of SBI extensions. Currently, this is implemented

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

Implement map_pages_to_xen() which requires several functions to manage page tables and entries: - pt_update() - pt_mapping_level() - pt_update_entry() - pt_next_level() - pt_check_entry() To support these operations, add functions for creating, mapping, and unmapping Xen tables: - create_table()

[PATCH v6 3/9] xen/riscv: allow write_atomic() to work with non-scalar types

Update the 2nd argument of _write_atomic() from 'unsigned long x' to 'void *x' to allow write_atomic() to handle non-scalar types, aligning it with read_atomic(), which can work with non-scalar types. Additionally, update the implementation of _add_sized() to use "writeX_cpu(readX_cpu(p) + x, p)"

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

Introduce arch_pmap_{un}map functions and select HAS_PMAP for CONFIG_RISCV. Add pte_from_mfn() for use in arch_pmap_map(). Introduce flush_xen_tlb_one_local() and use it in arch_pmap_{un}map(). Signed-off-by: Oleksii Kurochko Reviewed-by: Jan Beulich --- Changes in V6: - No changes ( only reb

[PATCH v6 0/9] RISCV device tree mapping

Current patch series introduces device tree mapping for RISC-V and necessary things for that such as: - Fixmap mapping - pmap - Xen page table processing --- Changes in v6: - Add patch to fix recursion when ASSERT(), BUG*(), panic() are called. - Add patch to allow write_atomic() to work with n

[PATCH v6 6/9] xen/riscv: introduce functionality to work with CPU info

Introduce struct pcpu_info to store pCPU-related information. Initially, it includes only processor_id and hart id, but it will be extended to include guest CPU information and temporary variables for saving/restoring vCPU registers. Add set_processor_id() and get_processor_id() functions to set a

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

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 --- Changes in V6: - Nothing changed. Only rebase. --- Changes in V5: - drop usage of PTE_BLOCK for flag argume

[PATCH v6 4/9] xen/riscv: set up fixmap mappings

Set up fixmap mappings and the L0 page table for fixmap support. Modify the Page Table Entries (PTEs) directly in arch_pmap_map() instead of using set_fixmap() ( which relies on map_pages_to_xen() ). This change is necessary because PMAP is used when the domain map page infrastructure is not yet i

[PATCH v6 1/9] xen/riscv: prevent recursion when ASSERT(), BUG*(), or panic() are called

Implement machine_restart() using printk() to prevent recursion that occurs when ASSERT(), BUG*(), or panic() are invoked. All these macros (except panic() which could be called directly) eventually call panic(), which then calls machine_restart(), leading to a recursive loop. Signed-off-by: Oleks

[PATCH v6 2/9] xen/riscv: use {read,write}{b,w,l,q}_cpu() to define {read,write}_atomic()

The functions {read,write}{b,w,l,q}_cpu() do not need to be memory-ordered atomic operations in Xen, based on their definitions for other architectures. Therefore, {read,write}{b,w,l,q}_cpu() can be used instead of {read,write}{b,w,l,q}(), allowing the caller to decide if additional fences should

Re: [PATCH] tools/ocaml/xc: Drop the GC lock for all hypercalls

On Mon, Sep 2, 2024 at 5:38 PM Andrew Cooper wrote: > > On 02/09/2024 9:10 am, Edwin Torok wrote: > > On Fri, Aug 30, 2024 at 6:53 PM Andrew Cooper > > wrote: > >> We should be doing this unilaterally. > > Agreed, but we should do it safely, since last time I did this I > > learned about a few m

Re: Block protocol incompatibilities with 4K logical sector size disks

On Mon, Sep 02, 2024 at 03:50:05PM +, Anthony PERARD wrote: > On Mon, Sep 02, 2024 at 05:23:37PM +0200, Roger Pau Monné wrote: > > On Mon, Sep 02, 2024 at 03:19:56PM +0100, Paul Durrant wrote: > > > On 02/09/2024 09:55, Roger Pau Monné wrote: > > > [snip] > > > > > > > > Thanks for your input.

[PATCH v2] x86/boot: Use fastcall for 32bit code

This is marginally more efficient, but is mostly to get rid of the use of stdcall in cmdline.c and reloc.c No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Frediano Ziglio v2: * Fixed up to work properly. I'm tempted to rebase this ahead of "[P

Re: [PATCH] tools/ocaml/xc: Drop the GC lock for all hypercalls

On 02/09/2024 9:12 am, Christian Lindig wrote: >> On 30 Aug 2024, at 18:53, Andrew Cooper wrote: >> >> We should be doing this unilaterally. > Acked-by: Christian Lindig Thanks. > > I would prefer to use caml_release_runtime_system(), > caml_acquire_runtime_system() which I think is a better n

Re: [XEN PATCH v2 3/3] libxl: Update the documentation of libxl_xen_console_read_line()

On Fri, Aug 23, 2024 at 06:31:50PM GMT, Andrew Cooper wrote: > On 23/08/2024 6:05 pm, Javi Merino wrote: > > diff --git a/tools/libs/light/libxl_console.c > > b/tools/libs/light/libxl_console.c > > index f42f6a51ee6f..652897e4ef6d 100644 > > --- a/tools/libs/light/libxl_console.c > > +++ b/tools/l

Re: [XEN PATCH v2 3/3] libxl: Update the documentation of libxl_xen_console_read_line()

On Tue, Aug 27, 2024 at 03:26:09PM GMT, Anthony PERARD wrote: > On Fri, Aug 23, 2024 at 06:05:05PM +0100, Javi Merino wrote: > > Despite its name, libxl_xen_console_read_line() does not read a line, > > it fills the buffer with as many characters as fit. Update the > > documentation to reflect the

[XEN PATCH v3 3/3] libxl: Update the documentation of libxl_xen_console_read_line()

Despite its name, libxl_xen_console_read_line() does not read a line, it fills the buffer with as many characters as fit. Update the documentation to reflect the real behaviour of the function. Rename line_r to avoid confusion since it is a pointer to an array of characters. Signed-off-by: Javi

[XEN PATCH v3 1/3] libxl: Fix nul-termination of the return value of libxl_xen_console_read_line()

When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)" call in main_dmesg(). ASAN reports a heap buffer overflow: an off-by-one access to cr->buffer. The readconsole sysctl copies up to count characters into the buffer, but it does not add a null character at the end. Despite the d

[XEN PATCH v3 2/3] libxl: Remove unnecessary buffer zeroing and zalloc()

When reading the console, xen overwrites the contents of the buffer, so there is no need to zero the buffer before passing it to xen. Instead, add a NULL at the end of the buffer. While we are at it, change the zalloc() of the buffer back to malloc() as it was before bdf4131 (libxl: don't leak buf

[XEN PATCH v3 0/3] libxl: Fixes for libxl_xenconsole_readline()

Fix nul-termination of the return value of libxl_xen_console_read_line(). While at it, remove unneeded memset()s to the buffer and improve the documentation of the function. Changes since v2[0]: - Fixed comment format as suggested by Anthony - Clarified that 16384 is the default size of xen's

Re: [PATCH] tools/ocaml/xc: Drop the GC lock for all hypercalls

On 02/09/2024 9:10 am, Edwin Torok wrote: > On Fri, Aug 30, 2024 at 6:53 PM Andrew Cooper > wrote: >> We should be doing this unilaterally. > Agreed, but we should do it safely, since last time I did this I > learned about a few more instances of behaviours I previously thought > to be safe, but

Re: [PATCH 2/4] x86/boot: Use

On 02/09/2024 4:47 pm, Frediano Ziglio wrote: > On Mon, Sep 2, 2024 at 2:32 PM Andrew Cooper > wrote: >> diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h >> index 44d723fd121a..19caaa8026ea 100644 >> --- a/xen/include/xen/macros.h >> +++ b/xen/include/xen/macros.h >> @@ -101,6 +10

Re: Block protocol incompatibilities with 4K logical sector size disks

On Mon, Sep 02, 2024 at 05:23:37PM +0200, Roger Pau Monné wrote: > On Mon, Sep 02, 2024 at 03:19:56PM +0100, Paul Durrant wrote: > > On 02/09/2024 09:55, Roger Pau Monné wrote: > > [snip] > > > > > > Thanks for your input. I would also like to hear from the blktap and > > > Windows PV drivers main

Re: [PATCH 2/4] x86/boot: Use

On Mon, Sep 2, 2024 at 2:32 PM Andrew Cooper wrote: > > ... rather than opencoding locally. > > This involve collecting various macros scattered around Xen (min()/max() > macros from kernel.h, and _p() from lib.h) and moving them into macros.h > > In reloc.c, replace ALIGN_UP() with ROUNDUP(). > >

Re: [PATCH 4/4] x86/boot: Use fastcall for 32bit code

On 02/09/2024 4:39 pm, Jan Beulich wrote: > On 02.09.2024 15:32, Andrew Cooper wrote: >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> CC: Frediano Ziglio >> >> RFC. This doesn't boot, but I haven't quite figured out where yet. > Because you got the register

Re: [PATCH 4/4] x86/boot: Use fastcall for 32bit code

On 02.09.2024 15:32, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Frediano Ziglio > > RFC. This doesn't boot, but I haven't quite figured out where yet. Because you got the register use wrong maybe? I think it's %eax, %edx, and then

Re: [PATCH] x86/cpu: revert opt_allow_unsafe from __ro_after_init to __read_mostly

On 02.09.2024 17:30, Roger Pau Monné wrote: > On Mon, Sep 02, 2024 at 05:16:05PM +0200, Jan Beulich wrote: >> On 02.09.2024 17:00, Roger Pau Monne wrote: >>> Making opt_allow_unsafe read only after init requires changes to the logic >>> in >>> init_amd(), otherwise the following #PF happens on CPU

Re: [PATCH 3/4] x86/boot: Use

On 02.09.2024 15:32, Andrew Cooper wrote: > ... rather than opencoding locally. __stdcall is x86-only and not something > we want to introduce to Xen generically, so opencode it in the two positions > where it matters. > > With this, defs.h is empty so delete it. > > No functional change. > > S

Re: [PATCH] x86/cpu: revert opt_allow_unsafe from __ro_after_init to __read_mostly

On Mon, Sep 02, 2024 at 05:16:05PM +0200, Jan Beulich wrote: > On 02.09.2024 17:00, Roger Pau Monne wrote: > > Making opt_allow_unsafe read only after init requires changes to the logic > > in > > init_amd(), otherwise the following #PF happens on CPU hotplug: > > > > [ Xen-4.20.0-1-d x86_64

Re: [PATCH 2/4] x86/boot: Use

On 02.09.2024 15:32, Andrew Cooper wrote: > ... rather than opencoding locally. > > This involve collecting various macros scattered around Xen (min()/max() > macros from kernel.h, and _p() from lib.h) and moving them into macros.h > > In reloc.c, replace ALIGN_UP() with ROUNDUP(). > > No functi

Re: Block protocol incompatibilities with 4K logical sector size disks

On Mon, Sep 02, 2024 at 03:50:17PM +0100, Mark Syms wrote: > On Mon, 2 Sept 2024 at 09:55, Roger Pau Monné wrote: > > > > > So yes, after more research, having sector in the protocol been a > > > 512-byte size seems the least bad option. "sector_number" and > > > "{first,last}_sect" have been desc

Re: Block protocol incompatibilities with 4K logical sector size disks

On 02/09/2024 16:23, Roger Pau Monné wrote: On Mon, Sep 02, 2024 at 03:19:56PM +0100, Paul Durrant wrote: On 02/09/2024 09:55, Roger Pau Monné wrote: [snip] Thanks for your input. I would also like to hear from the blktap and Windows PV drivers maintainers, as the change that I'm proposing he

Re: Block protocol incompatibilities with 4K logical sector size disks

On Mon, Sep 02, 2024 at 03:19:56PM +0100, Paul Durrant wrote: > On 02/09/2024 09:55, Roger Pau Monné wrote: > [snip] > > > > Thanks for your input. I would also like to hear from the blktap and > > Windows PV drivers maintainers, as the change that I'm proposing here > > will require changes to t

Re: [PATCH] x86/cpu: revert opt_allow_unsafe from __ro_after_init to __read_mostly

On 02.09.2024 17:00, Roger Pau Monne wrote: > Making opt_allow_unsafe read only after init requires changes to the logic in > init_amd(), otherwise the following #PF happens on CPU hotplug: > > [ Xen-4.20.0-1-d x86_64 debug=y Tainted: H ] > CPU:1 > RIP:e008:[] arch/x86/cpu/

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

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 callers to be able to derive e.g. exception context (t

Re: [XEN PATCH v2 3/3] libxl: Update the documentation of libxl_xen_console_read_line()

On Mon, Sep 02, 2024 at 11:14:11AM GMT, Alejandro Vallejo wrote: > On Fri Aug 23, 2024 at 6:05 PM BST, Javi Merino wrote: > > Despite its name, libxl_xen_console_read_line() does not read a line, > > it fills the buffer with as many characters as fit. Update the > > documentation to reflect the re

Re: [XEN PATCH v2 1/3] libxl: Fix nul-termination of the return value of libxl_xen_console_read_line()

On Mon, Sep 02, 2024 at 09:50:28AM GMT, Roger Pau Monné wrote: > On Fri, Aug 30, 2024 at 08:22:29PM +0100, Andrew Cooper wrote: > > On 29/08/2024 4:53 pm, Roger Pau Monné wrote: > > > On Fri, Aug 23, 2024 at 06:05:03PM +0100, Javi Merino wrote: > > >> When built with ASAN, "xl dmesg" crashes in the

[PATCH] x86/cpu: revert opt_allow_unsafe from __ro_after_init to __read_mostly

Making opt_allow_unsafe read only after init requires changes to the logic in init_amd(), otherwise the following #PF happens on CPU hotplug: [ Xen-4.20.0-1-d x86_64 debug=y Tainted: H ] CPU:1 RIP:e008:[] arch/x86/cpu/amd.c#init_amd+0x37f/0x993 [...] Xen call trace: [] R

[xen-unstable test] 187453: trouble: blocked/broken/preparing/queued/running

flight 187453 xen-unstable running [real] http://logs.test-lab.xenproject.org/osstest/logs/187453/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-amd64-xtf

Re: [XEN PATCH v2 1/3] libxl: Fix nul-termination of the return value of libxl_xen_console_read_line()

On Tue, Aug 27, 2024 at 03:20:10PM GMT, Anthony PERARD wrote: > On Fri, Aug 23, 2024 at 06:05:03PM +0100, Javi Merino wrote: > > diff --git a/tools/libs/light/libxl_console.c > > b/tools/libs/light/libxl_console.c > > index a563c9d3c7f9..012fd996fba9 100644 > > --- a/tools/libs/light/libxl_console

Re: Block protocol incompatibilities with 4K logical sector size disks

On Mon, 2 Sept 2024 at 09:55, Roger Pau Monné wrote: > > > So yes, after more research, having sector in the protocol been a > > 512-byte size seems the least bad option. "sector_number" and > > "{first,last}_sect" have been described as is for a long while. Only > > "sectors" for the size has bee

Re: [PATCH v1 2/4] xen/arm: mpu: Define Xen start address for MPU systems

On 28/08/2024 15:49, Julien Grall wrote: Hi, Hi Julien, On 23/08/2024 17:31, Ayan Kumar Halder wrote: From: Wei Chen On Armv8-A, Xen has a fixed virtual start address (link address too) for all Armv8-A platforms. In an MMU based system, Xen can map its loaded address to this virtual start

Re: Block protocol incompatibilities with 4K logical sector size disks

On 02/09/2024 09:55, Roger Pau Monné wrote: [snip] Thanks for your input. I would also like to hear from the blktap and Windows PV drivers maintainers, as the change that I'm proposing here will require changes to their implementations. So IIUC you are proposing to refuse to connect to a fro

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

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 callers to be able to derive e.g. exception context (to be > injected to the guest) - CR2 for #PF in

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

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, starting with x86 setup and converting the fi

[PATCH 3/4] x86/boot: Use

... rather than opencoding locally. __stdcall is x86-only and not something we want to introduce to Xen generically, so opencode it in the two positions where it matters. With this, defs.h is empty so delete it. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger

[PATCH 1/4] x86/boot: Use

... rather than opencoding locally. This also covers NULL and *_MAX. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné CC: Frediano Ziglio --- xen/arch/x86/boot/cmdline.c | 2 ++ xen/arch/x86/boot/defs.h| 17 ---

[PATCH 4/4] x86/boot: Use fastcall for 32bit code

Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Frediano Ziglio RFC. This doesn't boot, but I haven't quite figured out where yet. --- xen/arch/x86/boot/Makefile | 2 +- xen/arch/x86/boot/cmdline.c | 7 +++ xen/arch/x86/boot/head.S| 15 +-- xen

[PATCH 2/4] x86/boot: Use

... rather than opencoding locally. This involve collecting various macros scattered around Xen (min()/max() macros from kernel.h, and _p() from lib.h) and moving them into macros.h In reloc.c, replace ALIGN_UP() with ROUNDUP(). No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Be

[PATCH 0/4] xen/boot: Remove defs.h

Patch 1 posted in isolation before. Patches 2 and 3 complete the removal of defs.h. Patch 4 doesn't work yet and needs further debugging. Andrew Cooper (4): x86/boot: Use x86/boot: Use x86/boot: Use x86/boot: Use fastcall for 32bit code xen/arch/x86/boot/Makefile | 2 +- xen/arch/

[linux-linus test] 187452: trouble: blocked/broken

flight 187452 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/187452/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvops

[xen-unstable-smoke test] 187456: trouble: blocked/broken

flight 187456 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/187456/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-arm64-xs

[ANNOUNCE] Call for agenda items - Community Call 5th September 2024

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

Follow up discussion for: [RFC v2] Introduce SCI-mediator feature

Greetings, After some time we are back to the development of the SCI-Mediator feature presented as RFC few years earlier. Link to the RFC v2: https://lore.kernel.org/all/cover.1644341635.git.oleksii_moisie...@epam.com/ Last time feature discussion was stalled at the following point: - Device-tr

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

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 callers to be able to derive e.g. exception context (to be injected to the guest) - CR2 for #PF in particular - from the value. To simplify things ra

Re: [PATCH] x86/boot: Use

On 02.09.2024 14:12, Andrew Cooper wrote: > On 02/09/2024 1:07 pm, Jan Beulich wrote: >> On 02.09.2024 13:59, Andrew Cooper wrote: >>> --- a/xen/arch/x86/boot/cmdline.c >>> +++ b/xen/arch/x86/boot/cmdline.c >>> @@ -31,6 +31,8 @@ asm ( >>> ); >>> >>> #include >>> +#include >> And why not i

Re: [PATCH] x86/boot: Use

On 02/09/2024 1:07 pm, Jan Beulich wrote: > On 02.09.2024 13:59, Andrew Cooper wrote: >> --- a/xen/arch/x86/boot/cmdline.c >> +++ b/xen/arch/x86/boot/cmdline.c >> @@ -31,6 +31,8 @@ asm ( >> ); >> >> #include >> +#include > And why not include the file centrally ... > >> --- a/xen/arch/x86

Re: [PATCH] x86/boot: Use

On 02.09.2024 13:59, Andrew Cooper wrote: > --- a/xen/arch/x86/boot/cmdline.c > +++ b/xen/arch/x86/boot/cmdline.c > @@ -31,6 +31,8 @@ asm ( > ); > > #include > +#include And why not include the file centrally ... > --- a/xen/arch/x86/boot/defs.h > +++ b/xen/arch/x86/boot/defs.h > @@ -20

[PATCH] x86/boot: Use

... rather than defining them locally. This also covers NULL and *_MAX. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Frediano Ziglio --- xen/arch/x86/boot/cmdline.c | 2 ++ xen/arch/x86/boot/defs.h| 17 - xen/arch/x86/boot/reloc.c | 2 ++ 3

[xen_fbfront] - Xen PVH VM: kernel upgrade 6.9.10 > 6.10.7 results in crash

After upgrading kernel 6.9.10 to 6.10.7 all Xen PVH VM's became unavailable. Downgrading the kernel back to 6.9.10 makes the VM's work again. Snippet stack trace + kernel logs (good and bad) attached. Sep 01 08:59:21 web3..com kernel: xen_netfront: Initialising Xen virtual ethernet driver

Re: [xen_netfront] - Xen PVH VM: kernel upgrade 6.9.10 > 6.10.7 results in crash

On Mon, 2 Sept 2024 at 10:40, Jan Beulich wrote: > On 02.09.2024 10:32, Arthur Borsboom wrote: > > On Mon, 2 Sept 2024 at 10:27, Jan Beulich wrote: > > > >> On 01.09.2024 10:54, Arthur Borsboom wrote: > >>> After upgrading kernel 6.9.10 to 6.10.7 all Xen PVH VM's became > >> unavailable. > >>> D

Re: [PATCH v4 00/44] Boot modules for Hyperlaunch

On 8/30/24 17:46, Daniel P. Smith wrote: The Boot Modules for Hyperlaunch series is an effort to split out preliminary changes necessary for the introduction of the Hyperlaunch domain builder logic. These preliminary changes revolve around introducing the struct boot_module and struct boot_domain

Re: [PATCH] x86/boot: Use C99 types for integers

On 02/09/2024 11:16 am, Andrew Cooper wrote: > On 29/08/2024 2:42 pm, Frediano Ziglio wrote: >> On Thu, Aug 29, 2024 at 1:07 PM Andrew Cooper >> wrote: >>> On 29/08/2024 12:52 pm, Frediano Ziglio wrote: diff --git a/xen/arch/x86/boot/defs.h b/xen/arch/x86/boot/defs.h index 239b9f8716..e

Re: [PATCH] x86/boot: Use C99 types for integers

On 29/08/2024 2:42 pm, Frediano Ziglio wrote: > On Thu, Aug 29, 2024 at 1:07 PM Andrew Cooper > wrote: >> On 29/08/2024 12:52 pm, Frediano Ziglio wrote: >>> diff --git a/xen/arch/x86/boot/defs.h b/xen/arch/x86/boot/defs.h >>> index 239b9f8716..ee1a4da6af 100644 >>> --- a/xen/arch/x86/boot/defs.h

Re: [XEN PATCH v2 3/3] libxl: Update the documentation of libxl_xen_console_read_line()

On Fri Aug 23, 2024 at 6:05 PM BST, Javi Merino wrote: > Despite its name, libxl_xen_console_read_line() does not read a line, > it fills the buffer with as many characters as fit. Update the > documentation to reflect the real behaviour of the function. Rename > line_r to avoid confusion since i

[PATCH 2/4] ARM/vgic: Correct the expression for lr_all_full()

The current expression hits UB with 31 LRs (shifting into the sign bit), and malfunctions with 32 LRs (shifting beyond the range of int). Swapping 1 for 1ULL fixes some of these, but still malfunctions at 64 LRs which is the architectural limit. Instead, shift -1ULL right in order to create the m

[PATCH 3/4] ARM/vgic: Use for_each_set_bit() in gic_find_unused_lr()

There are no bits set in lr_mask beyond nr_lrs, so when substituting bitmap_for_each() for for_each_set_bit(), we don't need to worry about the upper bound. However, the type of lr_mask does matter, so switch it to be uint64_t * and move unsigned long * override until the find_next_zero_bit() call

[PATCH 1/4] ARM/div: Drop __div64_fls()

Following the improvements to Xen's bitops, fls() does constant propagation in all cases. Use it, and drop the local opencoded helper. No functional change. Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel

[PATCH 4/4] ARM/vgic: Use for_each_set_bit() in vgic-mmio*

These are all loops over a scalar value, and don't need to call general bitop helpers behind the scenes. No functional change. Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel Slighly RFC. It's unclear whe

[PATCH 0/4] ARM: Cleanup following bitops improvements

Patch 1 has been posted before, but is included here just so it doesn't get lost. Patch 2 is a bugfix found by code inspection. Patches 3 and 4 switch to a more efficient form. Andrew Cooper (4): ARM/div: Drop __div64_fls() ARM/vgic: Correct the expression for lr_all_full() ARM/vgic: Use f

[ovmf test] 187451: trouble: blocked/broken

flight 187451 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/187451/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvops

Re: IOREQ completions for MMIO writes

On 02/09/2024 10:28 am, Jan Beulich wrote: > On 29.08.2024 19:31, Andrew Cooper wrote: >> On 29/08/2024 5:08 pm, Jason Andryuk wrote: >>> Hi Everyone, >>> >>> I've been looking at ioreq latency and pausing of vCPUs.  Specifically >>> for MMIO (IOREQ_TYPE_COPY) writes, they still need completions: >

Re: IOREQ completions for MMIO writes

On 29.08.2024 19:31, Andrew Cooper wrote: > On 29/08/2024 5:08 pm, Jason Andryuk wrote: >> Hi Everyone, >> >> I've been looking at ioreq latency and pausing of vCPUs.  Specifically >> for MMIO (IOREQ_TYPE_COPY) writes, they still need completions: >> >> static inline bool ioreq_needs_completion(con

[qemu-mainline test] 187454: trouble: preparing/queued/running

flight 187454 qemu-mainline running [real] http://logs.test-lab.xenproject.org/osstest/logs/187454/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-thunderx queued test-arm64-arm64-xl

Re: [PATCH v2 2/2] x86/time: prefer CMOS over EFI_GET_TIME

On 02.09.2024 10:45, Roger Pau Monné wrote: > Is #PF the only fault that we can expect from EFI_GET_TIME? That's > what I've seen on some of the systems, but I wouldn't for example > discard #GP or #UD as also possible outcomes? I've definitely seen #GP in stack traces. What I can't say for sure

Re: Block protocol incompatibilities with 4K logical sector size disks

On Fri, Aug 30, 2024 at 04:09:25PM +, Anthony PERARD wrote: > On Thu, Aug 29, 2024 at 05:42:45PM +0200, Roger Pau Monné wrote: > > On Thu, Aug 29, 2024 at 01:15:42PM +, Anthony PERARD wrote: > > > On Thu, Aug 29, 2024 at 12:59:43PM +0200, Roger Pau Monné wrote: > > > > The following table a

Re: [PATCH v2] x86/cpufeatures: Add new cpuid features in SPR to featureset

On 02.09.2024 10:46, Alejandro Vallejo wrote: > On Wed Aug 21, 2024 at 5:07 PM BST, Jan Beulich wrote: >> On 21.08.2024 17:34, Matthew Barnes wrote: >>> Upon running `xen-cpuid -v` on a host machine with Sapphire Rapids >>> within Dom0, there exist unrecognised features. >>> >>> This patch adds the

Re: [PATCH v2] x86/cpufeatures: Add new cpuid features in SPR to featureset

On Wed Aug 21, 2024 at 5:07 PM BST, Jan Beulich wrote: > On 21.08.2024 17:34, Matthew Barnes wrote: > > Upon running `xen-cpuid -v` on a host machine with Sapphire Rapids > > within Dom0, there exist unrecognised features. > > > > This patch adds these features as macros to the CPU featureset, > >

Re: [PATCH v2 2/2] x86/time: prefer CMOS over EFI_GET_TIME

On Fri, Aug 30, 2024 at 05:31:04PM +0100, Andrew Cooper wrote: > On 30/08/2024 10:52 am, Roger Pau Monne wrote: > > The EFI_GET_TIME implementation is well known to be broken for many firmware > > implementations, for Xen the result on such implementations are: > > > > [ Xen-4.19-unstable x86_

Re: [xen_netfront] - Xen PVH VM: kernel upgrade 6.9.10 > 6.10.7 results in crash

On 02.09.2024 10:32, Arthur Borsboom wrote: > On Mon, 2 Sept 2024 at 10:27, Jan Beulich wrote: > >> On 01.09.2024 10:54, Arthur Borsboom wrote: >>> After upgrading kernel 6.9.10 to 6.10.7 all Xen PVH VM's became >> unavailable. >>> Downgrading the kernel back to 6.9.10 makes the VM's work again.

Re: [xen_netfront] - Xen PVH VM: kernel upgrade 6.9.10 > 6.10.7 results in crash

On Mon, 2 Sept 2024 at 10:27, Jan Beulich wrote: > On 01.09.2024 10:54, Arthur Borsboom wrote: > > After upgrading kernel 6.9.10 to 6.10.7 all Xen PVH VM's became > unavailable. > > Downgrading the kernel back to 6.9.10 makes the VM's work again. > > I don't think I can help with the crash, but:

Re: [xen_netfront] - Xen PVH VM: kernel upgrade 6.9.10 > 6.10.7 results in crash

On 01.09.2024 10:54, Arthur Borsboom wrote: > After upgrading kernel 6.9.10 to 6.10.7 all Xen PVH VM's became unavailable. > Downgrading the kernel back to 6.9.10 makes the VM's work again. I don't think I can help with the crash, but: How did you conclude it's xen-netfront? The data you provide .

Re: [PATCH] tools/libs/store: add missing USE_PTHREAD to target .o

On 31.08.2024 12:34, Andrei Stan wrote: > Ping This is pinging what exactly? From ... > On Fri, Jul 5, 2024 at 7:05 PM Andrei Stan wrote: >> >> On Fri, Jul 5, 2024 at 6:22 PM Jürgen Groß wrote: >>> >>> On 05.07.24 16:59, Andrei Stan wrote: Currently only shared libraries build with USE_PTH

Re: [PATCH] tools/ocaml/xc: Drop the GC lock for all hypercalls

[gmail is a bit terrible and defaults to reply to single person not reply all, resent] There is one bug here that would cause a crash, and several instances of undefined behaviour. On Mon, Sep 2, 2024 at 9:10 AM Edwin Torok wrote: > > On Fri, Aug 30, 2024 at 6:53 PM Andrew Cooper > wrote: > >

Re: [PATCH v2 2/2] x86/time: prefer CMOS over EFI_GET_TIME

On 30.08.2024 18:31, Andrew Cooper wrote: > I think the init logic wants to be: >  * If ACPI says we have an RTC, use it. >  * If ACPI says we have no RTC, probe to see if it's really there. >  * If we genuinely seem to not have an RTC, probe EFI.  This would be > quite invasive in the #PF handler,

  1   2   >