flight 183241 linux-linus real [real]
flight 183244 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183241/
http://logs.test-lab.xenproject.org/osstest/logs/183244/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 183242 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183242/
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
Hi,
> On Oct 3, 2023, at 06:45, Stefano Stabellini wrote:
>
> On Mon, 2 Oct 2023, Federico Serafini wrote:
>> Add missing parameter names. No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Release-acked-by: Henry Wang
Kind regards,
Henry
Hi,
> On Oct 3, 2023, at 06:46, Stefano Stabellini wrote:
>
> On Mon, 2 Oct 2023, Federico Serafini wrote:
>> Make function declaration and definition consistent.
>> No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Release-acked-by: Henry
Hi Oleg,
You are getting this output:
> (XEN) d0v0 Forwarding AES operation: 3254779951 136bb000 ->
> f000
Which means that the guest physical address is 0x136bb000 and
the translated physical address is 0xf000. It generates an
error so you are asking if
On Mon, 2 Oct 2023, Julien Grall wrote:
> On 29/09/2023 21:29, Stefano Stabellini wrote:
> > I am very glad you managed to solve the issue!
> >
> > It is always difficult to know what is the right thing to do when the
> > firmware provides wrong or noncompliant information.
>
> I am a bit
On Mon, 2 Oct 2023, Federico Serafini wrote:
> Make function declaration and definition consistent.
> No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Mon, 2 Oct 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The definition of 'consoled_guest_tx' can be static inline,
> thereby fixing a violation of MISRA C:2012 Rule 8.4.
>
> Fixes: 5ef49f185c2d ("x86/pv-shim: shadow PV console's page for L2 DomU")
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The declarations for {create,replace}_grant_p2m_mapping are
> not visible when these functions are defined, therefore the right
> header needs to be included to allow them to be visible.
>
> Signed-off-by: Nicola Vetrini
> ---
>
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> As stated in rules.rst, functions used only in asm code
> are allowed to have no prior declaration visible when being
> defined, hence these functions are deviated.
> This also fixes violations of MISRA C:2012 Rule 8.4.
>
> Signed-off-by: Nicola Vetrini
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> These variables are only used by asm code, and therefore
> the lack of a declaration is justified by the corresponding
> SAF comment.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The headline of Directive 4.1 states: "Run-time failures shall be minimized".
> Thus, it requires the project to supply documentation that pertains the
> measures
> and techinques used to prevent run-time failures from happening. For ease of
> reading,
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The documentation pertaining Directive 4.1 is contained in docs/misra.
> The build script driving the analysis is amended to allow ECLAIR to
> analyze such file.
>
> Signed-off-by: Nicola Vetrini
Acked-by: Stefano Stabellini
> ---
> Changes in v3:
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> To be able to check for the existence of the necessary subsections in
> the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a source
> file that is built.
>
> This file is generated from 'C-runtime-failures.rst' in docs/misra
> and the
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The aforementioned directive requires the project to supply documentation
> on the measures taken towards the minimization of run-time failures.
>
> The actual content of the documentation still needs feedback from the
> community.
>
> The 'rules.rst'
On Mon, 2 Oct 2023, Bertrand Marquis wrote:
> > On 2 Oct 2023, at 10:26, Julien Grall wrote:
> > On 29/09/2023 20:48, Stefano Stabellini wrote:
> >> On Fri, 29 Sep 2023, Luca Fancellu wrote:
> On 29 Sep 2023, at 01:33, Stefano Stabellini
> wrote:
>
> On Wed, 27 Sep 2023,
Hi George,
Sebastien and others at Microchip would like to give an update about
their progress with Xen on RISC-V.
Cheers,
Stefano
On Mon, 2 Oct 2023, George Dunlap wrote:
> Hi all,
>
> The proposed agenda is in
> https://cryptpad.fr/pad/#/2/pad/edit/cQBSSCUBQj9es3-wcs7I+8Em/ and you
> can
Hi Stefano,
On 29/09/2023 21:29, Stefano Stabellini wrote:
I am very glad you managed to solve the issue!
It is always difficult to know what is the right thing to do when the
firmware provides wrong or noncompliant information.
I am a bit confused why you think the firmware is wrong here.
flight 183240 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183240/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 3c0b315d79eb67846d99060e51989ff62bb33464
baseline version:
xtf
flight 183239 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183239/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1a66bd51ca21f341281d8e3157d3d3f4a94fd26c
baseline version:
ovmf
flight 183236 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183236/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183234
test-amd64-amd64-xl-qemuu-win7-amd64
Hi,
On 02/10/2023 16:11, Roger Pau Monne wrote:
From: Jan Beulich
The registration by virtual/linear address has downsides: The access is
expensive for HVM/PVH domains. Furthermore for 64-bit PV domains the area
is inaccessible (and hence cannot be updated by Xen) when in guest-user
mode.
Hi,
On 02/10/2023 16:11, Roger Pau Monne wrote:
From: Jan Beulich
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the area is inaccessible (and hence cannot be updated by Xen)
when in
On 02/10/2023 16:11, Roger Pau Monne wrote:
From: Jan Beulich
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the areas are inaccessible (and hence cannot be updated by
Xen) when in
From: Jan Beulich
The registration by virtual/linear address has downsides: The access is
expensive for HVM/PVH domains. Furthermore for 64-bit PV domains the area
is inaccessible (and hence cannot be updated by Xen) when in guest-user
mode.
Introduce a new vCPU operation allowing to register
From: Jan Beulich
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the areas are inaccessible (and hence cannot be updated by
Xen) when in guest-user mode, and for HVM guests they may be
From: Jan Beulich
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, add the necessary fork handling (with the
backing function yet to be filled in).
Signed-off-by: Jan Beulich
From: Jan Beulich
Switch to using map_guest_area(). Noteworthy differences from
map_vcpu_info():
- remote vCPU-s are paused rather than checked for being down (which in
principle can change right after the check),
- the domain lock is taken for a much smaller region,
- the error code for an
From: Jan Beulich
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the area is inaccessible (and hence cannot be updated by Xen)
when in guest-user mode.
Introduce a new vCPU operation
From: Jan Beulich
Before adding a new vCPU operation to register the runstate area by
guest-physical address, add code to actually keep such areas up-to-date.
Note that updating of the area will be done exclusively following the
model enabled by VMASST_TYPE_runstate_update_flag for
From: Jan Beulich
Before adding a new vCPU operation to register the secondary time area
by guest-physical address, add code to actually keep such areas up-to-
date.
Note that pages aren't marked dirty when written to (matching the
handling of space mapped by map_vcpu_info()), on the basis that
From: Jan Beulich
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, add the necessary domain cleanup hooks.
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
Acked-by: Roger Pau
Instead let map_vcpu_info() and it's call to get_page_from_gfn()
populate the page in the child as needed. Also remove the bogus
copy_domain_page(): should be placed before the call to map_vcpu_info(),
as the later can update the contents of the vcpu_info page.
Note that this eliminates a bug in
Since it was indicated that introducing specific new vCPU ops may be
beneficial independent of the introduction of a fully physical-
address-based ABI flavor, here we go. There continue to be a few open
questions throughout the series, resolving of which was one of the main
goals of the earlier
From: Jan Beulich
While likely the guest would just re-register the same areas after
a possible resume, let's not take this for granted and avoid the risk of
otherwise corrupting guest memory.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
xen/arch/x86/pv/shim.c | 4
1 file
flight 183238 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183238/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f6a314e5b5dc9697308740b2ac391a3c21b26403
baseline version:
ovmf
On Mon, Oct 02, 2023 at 10:55:28AM +0200, Joel Granados via B4 Relay wrote:
> From: Joel Granados
>
> This commit comes at the tail end of a greater effort to remove the
> empty elements at the end of the ctl_table arrays (sentinels) which
> will reduce the overall build time size of the kernel
Hi,
> On 2 Oct 2023, at 10:26, Julien Grall wrote:
>
> Hi Stefano,
>
> On 29/09/2023 20:48, Stefano Stabellini wrote:
>> On Fri, 29 Sep 2023, Luca Fancellu wrote:
On 29 Sep 2023, at 01:33, Stefano Stabellini
wrote:
On Wed, 27 Sep 2023, Luca Fancellu wrote:
>
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/cQBSSCUBQj9es3-wcs7I+8Em/ and you
can edit to add items. Alternatively, you can reply to this mail
directly. I'll be running the meeting while Kelly is on PTO.
Agenda items appreciated a few days before the call: please put
Make function declaration and definition consistent.
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/include/asm/paging.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/include/asm/paging.h
b/xen/arch/x86/include/asm/paging.h
index
Link to v1:
> https://lore.kernel.org/r/20230928-jag-sysctl_remove_empty_elem_drivers-v1-0-e59120fca...@samsung.com
>
> Comments/feedback greatly appreciated
Same problem on powerpc CI tests, all boot target failed, most of them
with similar OOPS, see
https://patchwork.ozlabs.org/pro
On Thu, Sep 28, 2023 at 02:28:11PM -0400, Stewart Hildebrand wrote:
>
>
> On 9/28/23 04:28, Roger Pau Monné wrote:
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Sep 27, 2023 at
On Thu, Sep 28, 2023 at 01:48:59PM -0700, Stefano Stabellini wrote:
> On Thu, 28 Sep 2023, Roger Pau Monné wrote:
> > On Thu, Sep 28, 2023 at 11:32:22AM +0200, Jan Beulich wrote:
> > > On 28.09.2023 10:32, Roger Pau Monné wrote:
> > > > On Wed, Sep 27, 2023 at 04:20:04PM -0700, Stefano Stabellini
On Sun, Oct 1, 2023 at 12:28 AM Demi Marie Obenour
wrote:
>
> On Fri, Sep 29, 2023 at 05:42:16PM +0100, George Dunlap wrote:
> > The basic credit2 algorithm goes something like this:
> >
> > 1. All vcpus start with the same number of credits; about 10ms worth
> > if everyone has the same weight
>
flight 183235 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183235/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in
183229
On Mon, Oct 02, 2023 at 09:49:44AM +0200, Nicola Vetrini wrote:
> Some variables with external linkage used in C code do not have
> a visible declaration where they are defined. Providing such
> declaration also resolves violations of MISRA C:2012 Rule 8.4.
>
> Signed-off-by: Nicola Vetrini
>
Add missing parameter names. No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/arm/irq.c | 3 ++-
xen/arch/x86/include/asm/irq.h | 4 ++--
xen/arch/x86/irq.c | 8
xen/include/xen/irq.h | 21 +++--
4 files changed, 19
On Fri, Sep 29, 2023 at 02:17:30PM +0200, Joel Granados wrote:
> On Thu, Sep 28, 2023 at 03:36:55PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Sep 28, 2023 at 03:21:26PM +0200, Joel Granados via B4 Relay wrote:
> > > From: Joel Granados
> > >
> > > This commit comes at the tail end of a
Hello Stefano,
Hello Julien,
> OK I see the question is about the Xilinx Xen tree. In the logs below we
have:
I see. After the correction r2 to r1 CSU got aborted immediately.
(XEN) d0v0 Forwarding AES operation: 3254779951 136bb000 ->
f000
Received exception
MSR: 0x200,
Le 02/10/2023 à 10:47, Joel Granados a écrit :
> On Thu, Sep 28, 2023 at 04:31:30PM +, Christophe Leroy wrote:
> I followed this trace and proc_handler is correctly defined in tty_table
> (struct ctl_table) in drivers/tty/tty_io.c:tty_init and there is not
> path that changes these values.
On Mon, Oct 02, 2023 at 08:47:53AM +, Christophe Leroy wrote:
>
>
> Le 02/10/2023 à 10:17, Jiri Slaby a écrit :
> > On 28. 09. 23, 15:21, Joel Granados via B4 Relay wrote:
> >> From: Joel Granados
> >>
> >> This commit comes at the tail end of a greater effort to remove the
> >> empty
On 02. 10. 23, 10:55, Joel Granados via B4 Relay wrote:
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
What?
These commits remove the sentinel element (last empty element) from the
sysctl arrays of all the files under the "drivers/" directory that use a
sysctl array for registration. The merging of the preparation patches
(in
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
Hi Julien,
> On Oct 2, 2023, at 16:45, Julien Grall wrote:
>
> Hi,
>
> Adding Henry to release ack the patch.
Thanks.
>
> Cheers,
>
> On 28/09/2023 13:12, Ayan Kumar Halder wrote:
>> Change VPCU to vCPU.
>> Also add a space before '*/'.
>> Signed-off-by: Ayan Kumar Halder
>> Acked-by:
Le 02/10/2023 à 10:17, Jiri Slaby a écrit :
> On 28. 09. 23, 15:21, Joel Granados via B4 Relay wrote:
>> From: Joel Granados
>>
>> This commit comes at the tail end of a greater effort to remove the
>> empty elements at the end of the ctl_table arrays (sentinels) which
>> will reduce the
On Thu, Sep 28, 2023 at 04:31:30PM +, Christophe Leroy wrote:
>
>
> Le 28/09/2023 à 15:21, Joel Granados via B4 Relay a écrit :
> > From: Joel Granados
>
> Automatic test fails on powerpc, see
>
Hi,
Adding Henry to release ack the patch.
Cheers,
On 28/09/2023 13:12, Ayan Kumar Halder wrote:
Change VPCU to vCPU.
Also add a space before '*/'.
Signed-off-by: Ayan Kumar Halder
Acked-by: Julien Grall
---
Changes from -
v1 - 1. Change VCPU --> vCPU.
2. Add a space before '*/'.
Hi,
On 29/09/2023 09:07, Henry Wang wrote:
On Sep 29, 2023, at 16:04, Juergen Gross wrote:
On 29.09.23 09:58, Julien Grall wrote:
From: Julien Grall
Signed-off-by: Julien Grall
---
README | 16
SUPPORT.md | 2 +-
xen/Makefile | 2 +-
3 files changed, 10
Hi Stefano,
On 29/09/2023 20:48, Stefano Stabellini wrote:
On Fri, 29 Sep 2023, Luca Fancellu wrote:
On 29 Sep 2023, at 01:33, Stefano Stabellini wrote:
On Wed, 27 Sep 2023, Luca Fancellu wrote:
Currently the dom0less feature code is mostly inside domain_build.c
and setup.c, it is a feature
On 28. 09. 23, 15:21, Joel Granados via B4 Relay wrote:
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by
On Wed 27-09-23 18:21:19, Christian Brauner wrote:
> On Wed, 27 Sep 2023 11:34:07 +0200, Jan Kara wrote:
> > Create struct bdev_handle that contains all parameters that need to be
> > passed to blkdev_put() and provide bdev_open_* functions that return
> > this structure instead of plain bdev
The definition of 'consoled_guest_tx' can be static inline,
thereby fixing a violation of MISRA C:2012 Rule 8.4.
Fixes: 5ef49f185c2d ("x86/pv-shim: shadow PV console's page for L2 DomU")
Signed-off-by: Nicola Vetrini
---
xen/include/xen/consoled.h | 2 +-
1 file changed, 1 insertion(+), 1
The declarations for {create,replace}_grant_p2m_mapping are
not visible when these functions are defined, therefore the right
header needs to be included to allow them to be visible.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/grant_table.c | 3 +--
Some variables with external linkage used in C code do not have
a visible declaration where they are defined. Providing such
declaration also resolves violations of MISRA C:2012 Rule 8.4.
Signed-off-by: Nicola Vetrini
---
xen/arch/arm/include/asm/setup.h | 3 +++
The patches in this series aim to fix or deviate various instances where a
function or variable do not have a declaration visible when such entity is
defined (in violation of MISRA C:2012 Rule 8.4).
An exception listed under docs/misra/rules.rst allows asm-only functions and
variables to be
The function is used only within this file, and therefore can be static.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/mm/mem_access.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index
The missing header makes the declaration visible when the function
is defined, thereby fixing a violation of MISRA C:2012 Rule 8.4.
Fixes: 1366a0e76db6 ("x86/vm_event: add hvm/vm_event.{h,c}")
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/vm_event.c | 1 +
1 file changed, 1 insertion(+)
These variables are only used by asm code, and therefore
the lack of a declaration is justified by the corresponding
SAF comment.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/asm_defns.h | 1 +
xen/arch/x86/setup.c | 1 +
2 files changed, 2 insertions(+)
diff
As stated in rules.rst, functions used only in asm code
are allowed to have no prior declaration visible when being
defined, hence these functions are deviated.
This also fixes violations of MISRA C:2012 Rule 8.4.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/svm/intr.c | 1 +
On Sat, Sep 30, 2023 at 05:52:17PM +0100, Phillip Potter wrote:
> On Fri, Sep 29, 2023 at 02:17:30PM +0200, Joel Granados wrote:
> > On Thu, Sep 28, 2023 at 03:36:55PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 28, 2023 at 03:21:26PM +0200, Joel Granados via B4 Relay
> > > wrote:
> > > >
To be able to check for the existence of the necessary subsections in
the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a source
file that is built.
This file is generated from 'C-runtime-failures.rst' in docs/misra
and the configuration is updated accordingly.
Signed-off-by:
The headline of Directive 4.1 states: "Run-time failures shall be minimized".
Thus, it requires the project to supply documentation that pertains the measures
and techinques used to prevent run-time failures from happening. For ease of
reading, the documentation is in RST format, but since ECLAIR
The aforementioned directive requires the project to supply documentation
on the measures taken towards the minimization of run-time failures.
The actual content of the documentation still needs feedback from the
community.
The 'rules.rst' file is updated accordingly to mention the newly
added
The documentation pertaining Directive 4.1 is contained in docs/misra.
The build script driving the analysis is amended to allow ECLAIR to
analyze such file.
Signed-off-by: Nicola Vetrini
---
Changes in v3:
- amended prepare script.
---
automation/eclair_analysis/build.sh | 6 +++---
flight 183234 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183234/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183233
test-amd64-amd64-xl-qemuu-win7-amd64
91 matches
Mail list logo
