Juergen Gross, le jeu. 25 juil. 2024 08:42:54 +0200, a ecrit:
> Hide the sanity_check() function, as it is used nowhere. By putting it
> under #ifdef CONFIG_TEST it will stay around, but it won't be
> included in normal production builds.
>
> Call sanity_check() from the periodic thread of the tes
Hide the sanity_check() function, as it is used nowhere. By putting it
under #ifdef CONFIG_TEST it will stay around, but it won't be
included in normal production builds.
Call sanity_check() from the periodic thread of the test app, causing
a sanity check every second.
Since any application linke
On 25.07.24 08:29, Samuel Thibault wrote:
Jürgen Groß, le jeu. 25 juil. 2024 08:25:18 +0200, a ecrit:
On 25.07.24 00:44, Samuel Thibault wrote:
Hello,
Jürgen Groß, le mar. 23 juil. 2024 08:36:13 +0200, a ecrit:
On 22.07.24 23:35, Samuel Thibault wrote:
Juergen Gross, le lun. 22 juil. 2024 17
On 24.07.2024 19:52, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Signed-off-by: Victor Lira
> Requested-by: Stefano Stabellini
Note: Tags in chronological order, please. Stefano isn't likely to have
requested
that after you signed off on the change. As an aside, aiui Stefano requested
On 24.07.2024 19:48, Lira, Victor M wrote:
> On 7/24/2024 12:44 AM, Jan Beulich wrote:
>> Nit: In names of new files we prefer - over _.
>> +script_name=`basename "$0"`
> I have fixed the above comments in v2.
>
>>> +#!/bin/bash
>> Can we rely on bash to be there and at that location? As you using
Jürgen Groß, le jeu. 25 juil. 2024 08:25:18 +0200, a ecrit:
> On 25.07.24 00:44, Samuel Thibault wrote:
> > Hello,
> >
> > Jürgen Groß, le mar. 23 juil. 2024 08:36:13 +0200, a ecrit:
> > > On 22.07.24 23:35, Samuel Thibault wrote:
> > > > Juergen Gross, le lun. 22 juil. 2024 17:01:41 +0200, a ecri
On 25.07.24 00:44, Samuel Thibault wrote:
Hello,
Jürgen Groß, le mar. 23 juil. 2024 08:36:13 +0200, a ecrit:
On 22.07.24 23:35, Samuel Thibault wrote:
Juergen Gross, le lun. 22 juil. 2024 17:01:41 +0200, a ecrit:
Remove the sanity_check() function, as it is used nowhere.
Since any applicatio
On 24.07.2024 19:24, Andrew Cooper wrote:
> On 17/07/2024 1:37 pm, Jan Beulich wrote:
>> On 17.07.2024 13:12, Andrew Cooper wrote:
>>> static inline int
>>> hypercall_sched_op(
>>> int cmd, void *arg)
>>> {
>>> -return _hypercall2(int, sched_op, cmd, arg);
>>> +return _hypercall2(in
flight 186997 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186997/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6271b617b4e653029246152871cde93f3926e144
baseline version:
ovmf a96d2a8f2dd3eb7e32b38
flight 186993 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186993/
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
flight 186982 xen-4.19-testing real [real]
flight 186996 xen-4.19-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186982/
http://logs.test-lab.xenproject.org/osstest/logs/186996/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 186995 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186995/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf f37c4574dd79d058c035be989ac6648508556a1a
baseline version:
xtf 4172faef1c0dee027ddd3f
flight 186991 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186991/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a96d2a8f2dd3eb7e32b383821fe30cfd7cdb2248
baseline version:
ovmf a7abb77c599f4243d7dba
flight 186987 xen-unstable-smoke real [real]
flight 186990 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186987/
http://logs.test-lab.xenproject.org/osstest/logs/186990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
Hello,
Jürgen Groß, le mar. 23 juil. 2024 08:36:13 +0200, a ecrit:
> On 22.07.24 23:35, Samuel Thibault wrote:
> > Juergen Gross, le lun. 22 juil. 2024 17:01:41 +0200, a ecrit:
> > > Remove the sanity_check() function, as it is used nowhere.
> > >
> > > Since any application linked with Mini-OS c
On Wed, Jul 24, 2024 at 03:36:44PM +, Anthony PERARD wrote:
> On Wed, Jul 24, 2024 at 03:18:50PM +0200, Jan Beulich wrote:
> > On 24.07.2024 15:15, GitLab wrote:
> > >
> > >
> > > Pipeline #1385987377 has failed!
> > >
> > > Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> > >
On Wed, 24 Jul 2024, Jan Beulich wrote:
> On 24.07.2024 00:40, Stefano Stabellini wrote:
> > On Tue, 23 Jul 2024, Jan Beulich wrote:
> >> On 23.07.2024 10:15, Alessandro Zucchelli wrote:
> >>> This section explains which format should be followed by header
> >>> inclusion guards via a drop-down lis
flight 186988 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186988/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a7abb77c599f4243d7dbab552ec74ed4d0d0d152
baseline version:
ovmf a9c8c47d5347c74f5e7e7
On Wed, 24 Jul 2024, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Signed-off-by: Victor Lira
> Requested-by: Stefano Stabellini
> ---
> Notes:
> This is a utilty script for help with the MISRA process.
> This script matches all linker symbol names in linker script files for
> arm and x86
Le mer. 24 juil. 2024 à 21:56, Jason Andryuk a écrit :
>
> On 2024-07-24 13:48, Lira, Victor M wrote:
> >
> > On 7/24/2024 12:44 AM, Jan Beulich wrote:
> >> Nit: In names of new files we prefer - over _.
> >> +script_name=`basename "$0"`
> > I have fixed the above comments in v2.
> >
> >>> +#!/bin
Hi all,
As many in the community are aware, the Xen Project has been notified
that the facility hosting the physical hardware for OSSTest and some of
the GitLab runners will shut down by the end of October 2024. This
necessitates a shift in our operations.
Our community manager, Kelly, has dilige
flight 186979 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 186827
test-amd64-amd64-do
On 2024-07-24 13:48, Lira, Victor M wrote:
On 7/24/2024 12:44 AM, Jan Beulich wrote:
Nit: In names of new files we prefer - over _.
+script_name=`basename "$0"`
I have fixed the above comments in v2.
+#!/bin/bash
Can we rely on bash to be there and at that location? As you using any
bash-is
On Wed, 24 Jul 2024, Techguru wrote:
> Hello,
> Stefano, on IRC, suggested that I start a discussion on this mailing
> list regarding my intention to bring up a fully function XEN on Apple
> Silicon (M1 and beyond). I am in the process of getting up to speed
> on your governance policies, applied
flight 186986 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186986/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 4172faef1c0dee027ddd3ffdbc88fe20eb711e9c
baseline version:
xtf 3955325292f49257797f33
flight 186984 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186984/
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
From: Victor Lira
Signed-off-by: Victor Lira
Requested-by: Stefano Stabellini
---
Notes:
This is a utilty script for help with the MISRA process.
This script matches all linker symbol names in linker script files for
arm and x86.
Not included are symbol names starting with "." or symbol names e
On 7/24/2024 12:44 AM, Jan Beulich wrote:
Nit: In names of new files we prefer - over _.
+script_name=`basename "$0"`
I have fixed the above comments in v2.
+#!/bin/bash
Can we rely on bash to be there and at that location? As you using any
bash-isms in the script which cannot be avoided?
On 17/07/2024 1:37 pm, Jan Beulich wrote:
> On 17.07.2024 13:12, Andrew Cooper wrote:
>> Right now, the hypercall page is at a hardcoded physical address, and making
>> hypercalls involves indirect calls to compile-time constant addresses.
>> e.g. HYPERCALL_memory_op is:
>>
>> mov$0x80180,%ea
On Fri, Jul 12, 2024 at 02:07:47PM +0100, Fouad Hilly wrote:
> diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
> index 390969db3d1c..8de82e5b8a10 100644
> --- a/tools/misc/xen-ucode.c
> +++ b/tools/misc/xen-ucode.c
> @@ -71,12 +72,29 @@ static void show_curr_cpu(FILE *f)
> }
> }
flight 186978 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186978/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 5 host-install broken REGR. vs. 18697
On 23.07.2024 10:15, Alessandro Zucchelli wrote:
> From: Maria Celeste Cesario
>
> Edit inclusion guards in order to make them consistent with the
> estabilished naming conventions.
>
> No functional change.
>
> Signed-off-by: Maria Celeste Cesario
> Signed-off-by: Simone Ballarin
> Reviewe
On 23.07.2024 10:15, Alessandro Zucchelli wrote:
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -105,9 +105,14 @@ xlat-y := $(shell sed -ne 's,@arch@,$(compat-arch-y),g'
> -re 's,^[?!][[:blank:]]+
> xlat-y := $(filter $(patsubst compat/%,%,$(headers-y)),$(xlat-y))
>
> quiet_cmd
On 23.07.2024 10:15, Alessandro Zucchelli wrote:
> From: Simone Ballarin
>
> Amend inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guards must
On 23.07.2024 10:14, Alessandro Zucchelli wrote:
> From: Simone Ballarin
>
> Add or move inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guard
On Wed, 2024-07-24 at 11:50 +, Anthony PERARD wrote:
> On Tue, Jul 23, 2024 at 07:31:58PM +0200,
> oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote:
> > > Oleksii, this is a fix (for an incomplete fix) for 4.19.
> > > 76a484193d
> > > broke compatib
On Wed, Jul 24, 2024 at 03:18:50PM +0200, Jan Beulich wrote:
> On 24.07.2024 15:15, GitLab wrote:
> >
> >
> > Pipeline #1385987377 has failed!
> >
> > Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> > Branch: staging-4.19 (
> > https://gitlab.com/xen-project/hardware/xen/-/commit
Introduces functions to work with SBI RFENCE extenstion
which will be used to do various version of fences for
remote ( not local ) CPU.
Except that sbi_init() function and auxiliary functions and
macros definitions are introduced to proper initialization and
checking availability of SBI extenstio
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()
During the mentioned above function it is necessary to create Xen t
The patch introduces stuff needed to decode a reason of an
exception.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
Acked-by: Jan Beulich
---
Changes in V11:
- Nothing changed. Only rebase.
---
Changes in V10:
- add Acked-by: Jan Beulich
---
Changes in V9:
- This patch was reve
From: Shawn Anastasio
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.
Suggested-by: Julien Grall
Signed-off-by: Shawn Anastasio
Acked-by: Julien Grall
Signed-off-by: Oleksii Kurochko
---
Changes in V7:
- Nothing changed. Only
Introduce a function to set up fixmap mappings and L0 page
table for fixmap.
Additionally, defines were introduced in riscv/config.h to
calculate the FIXMAP_BASE address.
This involved introducing BOOT_FDT_VIRT_{START, SIZE} and
XEN_VIRT_SIZE, XEN_VIRT_END.
Also, the check of Xen size was updated
Current patch series introduces device tree mapping for RISC-V
and necessary things for that such as:
- Fixmap mapping
- pmap
- Xen page table processing
Also, it introduces common stuff for working with fdt which is
based on the patches from [1]:
[PATCH v4 2/6] xen/device-tree: Move Arm's setup
Introduces arch_pmap_{un}map functions and select HAS_PMAP
for CONFIG_RISCV.
Additionaly it was necessary to introduce functions:
- mfn_from_xen_entry
- mfn_to_pte
Also flush_xen_tlb_range_va_local() and flush_xen_tlb_one_local()
are introduced and use in arch_pmap_unmap().
Signed-off-by: Olek
struct pcpu_info is introduced to store pcpu related information.
At the moment, it is only processor_id but in the fututre it will be
guest cpu information and some temporary variables which will be
used during save/restore of vcpu registers.
set_processor_id() and get_processor_id() are introduc
As common code is available it is better to use printk() instead
of early_printk().
Also the printing of "Hello from RISC-V world" is dropped as
it is useless and "All set up is enough".
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V11:
- Nothing changed. Only rebase.
-
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
---
Changes in V3:
- Code style fixes
- s/SZ_2M/MB(2)
- fix condition to check if early_fdt_map() in setup.c return NULL or not.
---
Ch
Introduces testing of some macros from .
Also wraps this testing into SELF_TESTS config to not produce
a noise in the log related to functionality testing ( in the
current case, it is macros from xen/bug.h ) when CONFIG_SELF_TESTS
is disabled.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair F
Enable build of generic functionality for working with device
tree for RISC-V.
Also, a collection of functions for parsing memory map and other
boot information from a device tree are available now.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V3:
- add Acked-by: Jan Beu
The patch series is based on:
Enable build of full Xen for RISC-V [1]
which haven't fully been merged yet.
The patch series provides a basic implementation of exception handling.
It can do only basic things such as decode a cause of an exception,
save/restore registers and execute "wfi" instru
To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
it is needed to enable GENERIC_BUG_FRAME.
ebreak is used as BUG_insn so when macros from are
used, an exception with BREAKPOINT cause will be generated.
ebreak triggers a debug trap, which starts in debug mode and is
then filtered
Note that trap_init() isn't declared with the __init attribute to
avoid removing __init when multi-CPU support for Xen is added.
Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
Acked-by: Jan Beulich
---
Changes in V11:
- update the commit message
- add Acked-by: Jan Beulich
-
On Wed Jul 24, 2024 at 2:01 PM BST, Jan Beulich wrote:
> On 24.07.2024 14:51, Matthew Barnes wrote:
> > On Wed, Jul 24, 2024 at 07:42:19AM +0200, Jan Beulich wrote:
> >> (re-adding xen-devel@)
> >>
> >> On 23.07.2024 14:57, Matthew Barnes wrote:
> >>> On Mon, Jul 22, 2024 at 01:37:11PM +0200, Jan B
On 24.07.2024 15:28, Alejandro Vallejo wrote:
> On Wed Jul 24, 2024 at 6:42 AM BST, Jan Beulich wrote:
>> On 23.07.2024 15:47, Alejandro Vallejo wrote:
>>> On Mon Jul 22, 2024 at 11:18 AM BST, Andrew Cooper wrote:
+if ( (eax >> 16) != 0x8000 || eax < 0x8000U )
+blexit(L"In
flight 186981 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186981/
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
On 22.07.2024 12:18, Andrew Cooper wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -738,29 +738,30 @@ static void __init efi_arch_handle_module(const struct
> file *file,
>
> static void __init efi_arch_cpu(void)
> {
> -uint32_t eax = cpuid_eax(0x800
On 2024-07-24 08:41, Jan Beulich wrote:
On 23.07.2024 17:04, Anthony PERARD wrote:
On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk wrote:
"$dev" needs to be set correctly for backendtype=phy as well as
backendtype=tap. Move the setting into the conditional, so it can be
handled properl
flight 186983 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186983/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a9c8c47d5347c74f5e7e7cb859912a276c6e9fb8
baseline version:
ovmf d4ae23b1e6c5fe9520581
On Wed Jul 24, 2024 at 6:42 AM BST, Jan Beulich wrote:
> On 23.07.2024 15:47, Alejandro Vallejo wrote:
> > On Mon Jul 22, 2024 at 11:18 AM BST, Andrew Cooper wrote:
> >> +if ( (eax >> 16) != 0x8000 || eax < 0x8000U )
> >> +blexit(L"In 64bit mode, but no extended CPUID leaves?!?");
>
On 2024-07-24 00:29, Stefano Stabellini wrote:
On Tue, 23 Jul 2024, Alessandro Zucchelli wrote:
From: Maria Celeste Cesario
Modify creation rule for asm-offsets.h to conform to
the new standard and to not generate conflicting guards
between architectures (which is a violation of the directive)
On 24.07.2024 15:15, GitLab wrote:
>
>
> Pipeline #1385987377 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging-4.19 (
> https://gitlab.com/xen-project/hardware/xen/-/commits/staging-4.19 )
>
> Commit: 2d7b6170 (
> https://gitlab.com/xen-project/ha
On 24.07.2024 14:51, Matthew Barnes wrote:
> On Wed, Jul 24, 2024 at 07:42:19AM +0200, Jan Beulich wrote:
>> (re-adding xen-devel@)
>>
>> On 23.07.2024 14:57, Matthew Barnes wrote:
>>> On Mon, Jul 22, 2024 at 01:37:11PM +0200, Jan Beulich wrote:
On 19.07.2024 16:21, Matthew Barnes wrote:
>
On Wed, Jul 24, 2024 at 07:42:19AM +0200, Jan Beulich wrote:
> (re-adding xen-devel@)
>
> On 23.07.2024 14:57, Matthew Barnes wrote:
> > On Mon, Jul 22, 2024 at 01:37:11PM +0200, Jan Beulich wrote:
> >> On 19.07.2024 16:21, Matthew Barnes wrote:
> >>> Currently, OVMF is hard-coded to set up a maxi
On 23.07.2024 17:04, Anthony PERARD wrote:
> On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk wrote:
>> "$dev" needs to be set correctly for backendtype=phy as well as
>> backendtype=tap. Move the setting into the conditional, so it can be
>> handled properly for each.
>>
>> (dev could be c
On 24.07.2024 13:32, Federico Serafini wrote:
> On 24/07/24 11:45, Jan Beulich wrote:
>> On 15.07.2024 18:48, Federico Serafini wrote:
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -499,7 +499,7 @@ safe."
>>> -doc_end
On 24.07.2024 12:30, Andrew Cooper wrote:
> On 24/07/2024 8:34 am, Jan Beulich wrote:
>> On 23.07.2024 19:41, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c
>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
>>> @@ -71,7 +71,7 @@ int vmce_restore_vcpu(struct vcpu *v, const struct
>>> hvm_vmce
On Tue, Jul 23, 2024 at 07:31:58PM +0200, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote:
> > Oleksii, this is a fix (for an incomplete fix) for 4.19. 76a484193d
> > broke compatibility for block-tap with the blktap2 kernel model (when
> > adding support
Hello,
I'm investigating a block device performance issue on our system.
Our setup is as follows:
SoC: NXP IMX8DXP (arm64), Dual core Cortex A35
Flash: eMMC, HS400
Xen 4.18.1
Dom0 kernel: 6.1.55
DomU kernel: 6.1.14
Dom0 has two vcpu's and domU has one. We're using the xen-blkfront/back drivers
On 24/07/24 11:45, Jan Beulich wrote:
On 15.07.2024 18:48, Federico Serafini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -499,7 +499,7 @@ safe."
-doc_end
-doc_begin="Switch clauses ending with an explicit comment
flight 186977 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186977/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186959
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 24/07/2024 8:34 am, Jan Beulich wrote:
> On 23.07.2024 19:41, Andrew Cooper wrote:
>> Coverity complains about it being invalid. It turns out that it is a GCC-ism
>> to treat ll and L equivalently. C99 only permits L to mean long double.
>>
>> Convert all uses of L in to alternatives, either l
flight 186980 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186980/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d4ae23b1e6c5fe95205818fcae9d5561c20588d3
baseline version:
ovmf 9bc7a361200215fc5065d
On 24.07.2024 12:08, Andrew Cooper wrote:
> On 24/07/2024 8:56 am, Jan Beulich wrote:
>> On 23.07.2024 22:37, Andrew Cooper wrote:
>>> XenServer's instance of coverity complains of OVERFLOW_BEFORE_WIDEN in
>>> mask_and_ack_level_ioapic_irq(), which is ultimately because of v being
>>> unsigned long
On 24/07/2024 8:56 am, Jan Beulich wrote:
> On 23.07.2024 22:37, Andrew Cooper wrote:
>> XenServer's instance of coverity complains of OVERFLOW_BEFORE_WIDEN in
>> mask_and_ack_level_ioapic_irq(), which is ultimately because of v being
>> unsigned long, and (1U << ...) being 32 bits.
> Which of cour
On 24.07.2024 11:59, Sergiy Kibrik wrote:
> 22.07.24 14:43, Jan Beulich:
>> On 09.07.2024 08:05, Sergiy Kibrik wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -5197,7 +5197,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
>>> {
>>> case XEN_DOMCTL_DE
22.07.24 14:43, Jan Beulich:
On 09.07.2024 08:05, Sergiy Kibrik wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5197,7 +5197,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
{
case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON:
case XEN_DOMCTL_DEBUG_OP_SINGLE
: 368990a7fe30737c990f628a60d26d9854a9e690 [12/12] xen: fix multicall
debug data referencing
config: x86_64-randconfig-012-20240724
(https://download.01.org/0day-ci/archive/20240724/202407240907.u0njhgtu-...@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org
On 15.07.2024 18:48, Federico Serafini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -499,7 +499,7 @@ safe."
> -doc_end
>
> -doc_begin="Switch clauses ending with an explicit comment indicating the
> fallthrough in
On Wed, Jul 24, 2024 at 11:16:52AM +0200, Jan Beulich wrote:
> On 24.07.2024 11:13, Roger Pau Monné wrote:
> > On Wed, Jul 24, 2024 at 10:41:43AM +0200, Jan Beulich wrote:
> >> On 24.07.2024 10:28, Roger Pau Monné wrote:
> >>> The only way I've found to cope with this is to use something like:
> >>
On 24.07.2024 11:13, Roger Pau Monné wrote:
> On Wed, Jul 24, 2024 at 10:41:43AM +0200, Jan Beulich wrote:
>> On 24.07.2024 10:28, Roger Pau Monné wrote:
>>> The only way I've found to cope with this is to use something like:
>>>
>>> #define ALT_CALL_ARG(arg, n)
On Wed, Jul 24, 2024 at 10:41:43AM +0200, Jan Beulich wrote:
> On 24.07.2024 10:28, Roger Pau Monné wrote:
> > The only way I've found to cope with this is to use something like:
> >
> > #define ALT_CALL_ARG(arg, n)\
> > union {
On 24.07.2024 10:28, Roger Pau Monné wrote:
> The only way I've found to cope with this is to use something like:
>
> #define ALT_CALL_ARG(arg, n)\
> union { \
> typeof(arg) e[(sizeo
On Wed, Jul 24, 2024 at 08:39:05AM +0200, Jan Beulich wrote:
> On 23.07.2024 18:24, Alejandro Vallejo wrote:
> > On Tue Jul 23, 2024 at 5:09 PM BST, Roger Pau Monné wrote:
> >> On Tue, Jul 23, 2024 at 04:37:12PM +0100, Alejandro Vallejo wrote:
> >>> On Tue Jul 23, 2024 at 10:31 AM BST, Roger Pau Mo
On 24/07/2024 7:58 am, Jan Beulich wrote:
> On 18.07.2024 18:48, Andrew Cooper wrote:
>> While the purpose of this series is patch 6, it has a side effect of reducing
>> the number of system calls substantally.
>>
>> Using a strace of test-xenstore as an example, we go from this:
>>
>> rt_sigacti
On 23.07.2024 23:05, Andrew Cooper wrote:
> They're all within a 12 bit range of their respective bases, and this prevents
> all the MSR coordinates being calculated in %rcx.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> There's one unpleasant surprise hidden:
>
> add/remove:
On 23.07.2024 23:12, Andrew Cooper wrote:
> This allows for marginally better code generation including the use of BT
> rather than SHR/TEST.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 23.07.2024 22:37, Andrew Cooper wrote:
> XenServer's instance of coverity complains of OVERFLOW_BEFORE_WIDEN in
> mask_and_ack_level_ioapic_irq(), which is ultimately because of v being
> unsigned long, and (1U << ...) being 32 bits.
Which of course is bogus when the shift amount is masked down
On 24.07.2024 02:18, victorm.l...@amd.com wrote:
> --- /dev/null
> +++ b/automation/eclair_analysis/linker_symbols.sh
Nit: In names of new files we prefer - over _.
> @@ -0,0 +1,41 @@
> +#!/bin/bash
Can we rely on bash to be there and at that location? As you using any
bash-isms in the script wh
On 24.07.2024 08:27, Nicola Vetrini wrote:
> On 2024-07-24 02:18, victorm.l...@amd.com wrote:
>> --- /dev/null
>> +++ b/automation/eclair_analysis/stuff.txt
>
> I wouldn't include the actual output in the patch. It' much better if I
> have a script that produces a list of symbols, and then use th
On 23.07.2024 19:41, Andrew Cooper wrote:
> Coverity complains about it being invalid. It turns out that it is a GCC-ism
> to treat ll and L equivalently. C99 only permits L to mean long double.
>
> Convert all uses of L in to alternatives, either l, ll or PRI.64 depending on
> the operand type.
flight 186973 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186973/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 186827
test-amd64-amd64-do
On 24.07.2024 03:14, Techguru wrote:
> I am in the process of getting up to speed on your governance
> policies, applied for Coverity access to use some of the known issues
> there as training wheels, and putting my gitlab fork into good working
> order with CI.
>
> I would rather not duplicate ef
On Tue, 2024-07-23 at 14:05 -0400, Jason Andryuk wrote:
> On 2024-07-23 13:34, Andrew Cooper wrote:
> > On 23/07/2024 6:31 pm, oleksii.kuroc...@gmail.com wrote:
> > > On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote:
> > > > On 2024-07-23 11:04, Anthony PERARD wrote:
> > > > > On Mon, Jul 15,
93 matches
Mail list logo
