flight 184961 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184961/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 184942
build-arm64-pvops
Hi Julien,
On 3/9/2024 6:30 AM, Julien Grall wrote:
(+ Ayan + Henry)
(- my old email address + the new one)
Hi Carlo,
On 29/01/2024 17:18, Carlo Nonato wrote:
Cache coloring must physically relocate Xen in order to color the
hypervisor
and consider_modules() is a key function that is
flight 184965 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184965/
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
On Tue, Mar 5, 2024 at 2:13 PM Marek Marczykowski-Górecki
wrote:
>
> From: Frédéric Pierret (fepitre)
Needs to be changed to Marek.
> When running in a stubdomain, the config space access via sysfs needs to
> use BDF as seen inside stubdomain (connected via xen-pcifront), which is
> different
On Tue, Mar 5, 2024 at 2:13 PM Marek Marczykowski-Górecki
wrote:
>
> Introduce global xen_is_stubdomain variable when qemu is running inside
> a stubdomain instead of dom0. This will be relevant for subsequent
> patches, as few things like accessing PCI config space need to be done
> differently.
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-livepatch
testid livepatch-run
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu
I would like to resurrect this thread and ask other opinions.
On Thu, 23 Nov 2023, Jan Beulich wrote:
> On 22.11.2023 22:46, Stefano Stabellini wrote:
> > Two out of three do_multicall definitions/declarations use uint32_t as
> > type for the "nr_calls" parameters. Change the third one to be
> >
On Fri, 8 Mar 2024, Nicola Vetrini wrote:
> These constants are parenthesized to avoid them from
> possibly influencing the semantics of the constructs where it is used,
> especially inside macros invocations.
>
> This also resolves some violations of MISRA C Rule 20.7
> ("Expressions resulting
On Fri, 8 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On Fri, 8 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On Fri, 8 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On Fri, 8 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On Fri, 8 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On Fri, 8 Mar 2024, Federico Serafini wrote:
> Add missing break statements to address violations of MISRA C:2012
> Rule 16.3 ("An unconditional `break' statement shall terminate every
> switch-clause").
>
> Add missing default cases to address violations of MISRA C:2012
> Rule 16.4 (Every
On Fri, 8 Mar 2024, Nicola Vetrini wrote:
> Rule 20.4 states: "A macro shall not be defined with the same name
> as a keyword".
>
> Defining this macro with the same name as the inline keyword
> allows for additionally checking that out-of-lined static inline
> functions end up in the correct
flight 184942 linux-linus real [real]
flight 184958 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184942/
http://logs.test-lab.xenproject.org/osstest/logs/184958/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Carlo,
On 29/01/2024 17:18, Carlo Nonato wrote:
Signed-off-by: Carlo Nonato
---
v6:
- new patch
---
SUPPORT.md | 7 +++
I would consider to fold it in patch #1. So we could potentially to
start committing the series.
In any case:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi Carlo,
On 29/01/2024 17:18, Carlo Nonato wrote:
diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S
index fa40b696dd..7926849ab1 100644
--- a/xen/arch/arm/arm64/mmu/head.S
+++ b/xen/arch/arm/arm64/mmu/head.S
@@ -427,6 +427,60 @@ fail: PRINT("- Boot failed -\r\n")
(+ Ayan + Henry)
Hi Carlo,
On 29/01/2024 17:18, Carlo Nonato wrote:
Cache coloring must physically relocate Xen in order to color the hypervisor
and consider_modules() is a key function that is needed to find a new
available physical address.
672d67f339c0 ("xen/arm: Split MMU-specific
On Mon, Jan 29, 2024 at 05:44:43PM +0100, Philippe Mathieu-Daudé wrote:
> When a variable is initialized to >field, use it
> in place. Rationale: while this makes the code more concise,
> this also helps static analyzers.
>
> Mechanical change using the following Coccinelle spatch script:
>
>
On Fri, Mar 8, 2024 at 9:14 AM Marek Szyprowski
wrote:
>
> On 05.03.2024 04:05, Alexei Starovoitov wrote:
> > From: Alexei Starovoitov
> >
> > There are various users of get_vm_area() + ioremap_page_range() APIs.
> > Enforce that get_vm_area() was requested as VM_IOREMAP type and range
> >
On Fri, Jun 18, 2021 at 09:54:14AM +0100, Alex Bennée wrote:
>
> Marek Marczykowski-Górecki writes:
>
> > Kernel on Xen is loaded via fw_cfg. Previously it used non-DMA version,
> > which loaded the kernel (and initramfs) byte by byte. Change this
> > to DMA, to load in bigger chunks.
> > This
On 05.03.2024 04:05, Alexei Starovoitov wrote:
> From: Alexei Starovoitov
>
> There are various users of get_vm_area() + ioremap_page_range() APIs.
> Enforce that get_vm_area() was requested as VM_IOREMAP type and range
> passed to ioremap_page_range() matches created vm_area to avoid
>
Add the shutdown reasons to the paragraph of "xl list" concerning the
shutdown status.
I have adapted the explanations from the source code :
- tools/xl/xl_info.c : function "list_domains()", variable
"shutdown_reason_letters"
- xen/include/public/sched.h : variable "shed_shutdown_reason"
On 06 Mar 2024 16:43, Anthony PERARD wrote:
On Tue, Mar 05, 2024 at 11:45:13PM +0100, zithro / Cyril Rébert wrote:
Add the shutdown reasons to the paragraph of "xl list" concerning the
shutdown status.
I have copy/pasted the explanations from the source code :
- tools/xl/xl_info.c (L379)
Hi all,
The March community call recording has been uploaded:
https://youtu.be/IBKUEy5ZSrQ
This has also been saved in the Cryptpad file.
Many thanks,
Kelly Choi
Community Manager
Xen Project
Hi John,
Thank you for the reply.
On 08/03/2024 13:40, John Ernberg wrote:
On 3/7/24 00:07, Julien Grall wrote:
> Ping on the watchdog discussion bits.
Sorry for the late reply.
On 06/03/2024 13:13, John Ernberg wrote:
On 2/9/24 14:14, John Ernberg wrote:
* IMX_SIP_TIMER_*: This
On 08/03/2024 1:56 pm, Jan Beulich wrote:
> On 08.03.2024 14:45, osstest service owner wrote:
>> flight 184940 xen-unstable real [real]
>> flight 184945 xen-unstable real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/184940/
>>
On 08.03.2024 14:45, osstest service owner wrote:
> flight 184940 xen-unstable real [real]
> flight 184945 xen-unstable real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/184940/
> http://logs.test-lab.xenproject.org/osstest/logs/184945/
>
> Regressions :-(
>
> Tests which did
flight 184940 xen-unstable real [real]
flight 184945 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184940/
http://logs.test-lab.xenproject.org/osstest/logs/184945/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Julien,
On 3/7/24 00:07, Julien Grall wrote:
> Hi John,
>
> > Ping on the watchdog discussion bits.
>
> Sorry for the late reply.
>
> On 06/03/2024 13:13, John Ernberg wrote:
>> On 2/9/24 14:14, John Ernberg wrote:
>>>
* IMX_SIP_TIMER_*: This seems to be related to the watchdog.
On 08.03.2024 13:17, Oleksii wrote:
> On Fri, 2024-03-08 at 12:52 +0100, Jan Beulich wrote:
>> On 08.03.2024 12:49, Jan Beulich wrote:
>>> On 08.03.2024 11:14, Oleksii wrote:
On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote:
> On 07.03.2024 21:54, Oleksii wrote:
>> On Thu,
On 08.03.2024 13:01, Oleksii wrote:
> On Fri, 2024-03-08 at 09:22 +0100, Jan Beulich wrote:
>> On 07.03.2024 18:08, Oleksii wrote:
>>> On Fri, 2023-12-22 at 12:09 +0100, Jan Beulich wrote:
On 22.12.2023 10:39, Oleksii wrote:
> On Tue, 2023-08-08 at 12:32 +0200, Jan Beulich wrote:
>>
On Fri, 2024-03-08 at 12:52 +0100, Jan Beulich wrote:
> On 08.03.2024 12:49, Jan Beulich wrote:
> > On 08.03.2024 11:14, Oleksii wrote:
> > > On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote:
> > > > On 07.03.2024 21:54, Oleksii wrote:
> > > > > On Thu, 2024-03-07 at 21:49 +0100, Oleksii
flight 184943 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184943/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ccf91b518f22102d446f26320110d30ea0fc1fa9
baseline version:
ovmf
On Fri, 2024-03-08 at 09:22 +0100, Jan Beulich wrote:
> On 07.03.2024 18:08, Oleksii wrote:
> > On Fri, 2023-12-22 at 12:09 +0100, Jan Beulich wrote:
> > > On 22.12.2023 10:39, Oleksii wrote:
> > > > On Tue, 2023-08-08 at 12:32 +0200, Jan Beulich wrote:
> > > > > On 08.08.2023 12:18, Andrew Cooper
On 08.03.2024 12:49, Jan Beulich wrote:
> On 08.03.2024 11:14, Oleksii wrote:
>> On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote:
>>> On 07.03.2024 21:54, Oleksii wrote:
On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote:
> On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote:
>>
Add missing break statements to address violations of MISRA C:2012
Rule 16.3 ("An unconditional `break' statement shall terminate every
switch-clause").
Add missing default cases to address violations of MISRA C:2012
Rule 16.4 (Every `switch' statement shall have a `default' label).
No
On 08.03.2024 11:14, Oleksii wrote:
> On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote:
>> On 07.03.2024 21:54, Oleksii wrote:
>>> On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote:
On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote:
> For plain writes it should at least be "=Qo"
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
Hi all,
this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted
These constants are parenthesized to avoid them from
possibly influencing the semantics of the constructs where it is used,
especially inside macros invocations.
This also resolves some violations of MISRA C Rule 20.7
("Expressions resulting from the expansion of macro parameters shall
be
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
On 07.03.24 19:11, Uwe Kleine-König wrote:
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this
On Fri, 2024-03-08 at 08:26 +0100, Jan Beulich wrote:
> On 07.03.2024 21:54, Oleksii wrote:
> > On Thu, 2024-03-07 at 21:49 +0100, Oleksii wrote:
> > > On Thu, 2024-03-07 at 18:14 +0100, Jan Beulich wrote:
> > > > For plain writes it should at least be "=Qo" then, yes.
> > > Constraints Q is a
Le jeu. 7 mars 2024, 09:39, Jan Beulich a écrit :
> On 06.03.2024 18:28, Sébastien Chaumat wrote:
> > Reasoning backward (using a kernel without the pinctrl_amd driver to
> >> ensure xen only is at stake) :
> >> checking the diff in IOAPIC between bare metal and xen (IRQ7 is on
> >> pin07
On 08.03.2024 10:06, Henry Wang wrote:
> On 3/8/2024 4:59 PM, Michal Orzel wrote:
>> Another alternative would be to let the arch header define it if needed and
>> use a centralized stub in xen/domain.h:
>>
>> #ifndef is_domain_direct_mapped
>> #define is_domain_direct_mapped(d) ((void)(d), 0)
>>
Hi Michal,
On 3/8/2024 4:59 PM, Michal Orzel wrote:
Hi Henry,
On 08/03/2024 02:54, Henry Wang wrote:
Currently direct mapped domain is only supported by the Arm
architecture at the domain creation time by setting the CDF_directmap
flag. There is not a need for every non-Arm architecture, i.e.
Hi Henry,
On 08/03/2024 02:54, Henry Wang wrote:
> Currently direct mapped domain is only supported by the Arm
> architecture at the domain creation time by setting the CDF_directmap
> flag. There is not a need for every non-Arm architecture, i.e. x86,
> RISC-V and PPC, to define a stub
On 07.03.24 18:01, Jason Andryuk wrote:
On 2024-03-07 04:30, Roger Pau Monné wrote:
On Wed, Mar 06, 2024 at 01:50:32PM -0500, Jason Andryuk wrote:
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it
Hi Henry,
On 08/03/2024 03:05, Henry Wang wrote:
> Hi everyone,
>
> On 2/26/2024 6:43 PM, Michal Orzel wrote:
> xen/arch/arm/smpboot.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> +/* PE not implemented using a multithreading type approach. */
> +
Hi Michal,
On 3/8/2024 4:18 PM, Michal Orzel wrote:
Hi Henry,
On 08/03/2024 02:54, Henry Wang wrote:
Currently on Arm there are 4 functions to allocate memory as domain
RAM at boot time for different types of domains:
(1) allocate_memory(): To allocate memory for Dom0less DomUs that
do
On 07.03.2024 18:08, Oleksii wrote:
> On Fri, 2023-12-22 at 12:09 +0100, Jan Beulich wrote:
>> On 22.12.2023 10:39, Oleksii wrote:
>>> On Tue, 2023-08-08 at 12:32 +0200, Jan Beulich wrote:
On 08.08.2023 12:18, Andrew Cooper wrote:
> On 08/08/2023 10:46 am, Jan Beulich wrote:
>>
Hi Henry,
On 08/03/2024 02:54, Henry Wang wrote:
> Currently on Arm there are 4 functions to allocate memory as domain
> RAM at boot time for different types of domains:
> (1) allocate_memory(): To allocate memory for Dom0less DomUs that
> do not use static memory.
> (2)
Rule 20.4 states: "A macro shall not be defined with the same name
as a keyword".
Defining this macro with the same name as the inline keyword
allows for additionally checking that out-of-lined static inline
functions end up in the correct section while minimizing churn and
has a positive impact
59 matches
Mail list logo
