On 27/09/2023 15:29, Nicola Vetrini wrote:
On 27/09/2023 11:52, 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
---
Changes in v2:
-
On 27.09.2023 17:09, Federico Serafini wrote:
> Make function declarations and definitions consistent.
> No functional change.
>
> Signed-off-by: Federico Serafini
> ---
> xen/arch/x86/domain_page.c | 36 ++--
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
flight 183200 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183200/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f36e1ec1f0a5fd3be84913e09181d7813444b620
baseline version:
ovmf ad1c0394b1770315099e5
flight 183197 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183197/
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 183192 linux-5.4 real [real]
flight 183198 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183192/
http://logs.test-lab.xenproject.org/osstest/logs/183198/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On Wed, 27 Sep 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 Sep 28, 2023, at 08:49, Stefano Stabellini wrote:
>
> On Wed, 27 Sep 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
On Wed, 27 Sep 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 conf
On Wed, 27 Sep 2023, Bertrand Marquis wrote:
> > On 27 Sep 2023, at 09:53, Nicola Vetrini wrote:
> >
> >>> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> >>> > index 695d2fa1f1..2a8527cacc 100644
> >>> > --- a/xen/arch/arm/psci.c
> >>> > +++ b/xen/arch/arm/psci.c
> >>> > @@ -59,6 +59,
Hi Stefano,
> On Sep 28, 2023, at 08:22, Stefano Stabellini wrote:
>
> Hi Henry, since we are doing doc changes, would you also agree on this
> one?
>
Yes, same as the last patch that I just release acked.
Kind regards,
Henry
>
> On Wed, 27 Sep 2023, Bertrand Marquis wrote:
>> Hi Stefano,
Hi Henry, since we are doing doc changes, would you also agree on this
one?
On Wed, 27 Sep 2023, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 27 Sep 2023, at 03:05, Stefano Stabellini wrote:
> >
> > From: Stefano Stabellini
> >
> > Following up from the MISRA C group discussion, add Rule 1
On Thu, 28 Sep 2023, Andrew Cooper wrote:
> On 28/09/2023 12:04 am, Stefano Stabellini wrote:
> > On Mon, 25 Sep 2023, Henry Wang wrote:
> >> 3. dom0less vs xenstored setup race Was: xen | Failed pipeline for staging
> >> | 6a47ba2f
> >>
> >> https://marc.info/?l=xen-devel&m=168312468808977
> >>
>
Hi Stefano,
> On Sep 28, 2023, at 07:53, Stefano Stabellini wrote:
>
> Actually adding Henry
>
> On Wed, 27 Sep 2023, Stefano Stabellini wrote:
>> Hi Henry,
>>
>> This patch is now acked. Should it go in 4.18?
Sure, a doc change should be harmless so:
Release-acked-by: Henry Wang
Kind rega
Actually adding Henry
On Wed, 27 Sep 2023, Stefano Stabellini wrote:
> Hi Henry,
>
> This patch is now acked. Should it go in 4.18?
>
> In terms of risk of breaking, it is zero as nothing builds or runs based
> on this document.
>
> At the same time, the benefit is also low because the main val
Hi Henry,
This patch is now acked. Should it go in 4.18?
In terms of risk of breaking, it is zero as nothing builds or runs based
on this document.
At the same time, the benefit is also low because the main value of this
document is for future coding changes that would be too late now for
4.18.
On 28/09/2023 12:04 am, Stefano Stabellini wrote:
> On Mon, 25 Sep 2023, Henry Wang wrote:
>> 3. dom0less vs xenstored setup race Was: xen | Failed pipeline for staging |
>> 6a47ba2f
>>
>> https://marc.info/?l=xen-devel&m=168312468808977
>>
>> https://marc.info/?l=xen-devel&m=168312687610283
> For
Hi Stefano,
> On Sep 28, 2023, at 07:20, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> The feature is not commonly used, and we don't have hardware to test it,
> not in OSSTest, not in Gitlab, and not even ad-hoc manually by community
> members. We could use QEMU to test it, but e
From: Stefano Stabellini
The feature is not commonly used, and we don't have hardware to test it,
not in OSSTest, not in Gitlab, and not even ad-hoc manually by community
members. We could use QEMU to test it, but even that it is known not to
work.
Also take the opportunity to rename the feature
On Mon, 25 Sep 2023, Henry Wang wrote:
> 3. dom0less vs xenstored setup race Was: xen | Failed pipeline for staging |
> 6a47ba2f
>
> https://marc.info/?l=xen-devel&m=168312468808977
>
> https://marc.info/?l=xen-devel&m=168312687610283
For this issue I suggest to go with this fix unless someone
flight 183189 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183189/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183181
test-amd64-amd64-xl-qemut-win7-amd64
On 8/29/23 19:19, Volodymyr Babchuk wrote:
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index e96d7b2b37..3cc6a96849 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -161,63 +161,101 @@ static void modify_decoding(const struct pci_dev
> *pde
On 9/26/23 11:48, Roger Pau Monné wrote:
> On Tue, Sep 26, 2023 at 11:27:48AM -0400, Stewart Hildebrand wrote:
>> On 9/26/23 04:07, Roger Pau Monné wrote:
>>> On Mon, Sep 25, 2023 at 05:49:00PM -0400, Stewart Hildebrand wrote:
On 9/22/23 04:44, Roger Pau Monné wrote:
> On Tue, Aug 29, 2023
flight 183188 libvirt real [real]
flight 183195 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183188/
http://logs.test-lab.xenproject.org/osstest/logs/183195/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-lib
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 pointer. This will eventually allow
> us to pass one more argume
On 27.09.2023 17:50, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:58:01PM +0200, Jan Beulich wrote:
>> 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
On Wed, Sep 27, 2023 at 11:52:31AM +0200, 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
On Wed, May 03, 2023 at 05:58:01PM +0200, Jan Beulich wrote:
> 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.
>
> I
On 27.09.2023 17:24, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:57:40PM +0200, Jan Beulich wrote:
>> 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
On 27.09.2023 16:53, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:57:09PM +0200, Jan Beulich wrote:
>> RFC: In map_guest_area() I'm not checking the P2M type, instead - just
>> like map_vcpu_info() - solely relying on the type ref acquisition.
>> Checking for p2m_ram_rw alone would
On Wed, May 03, 2023 at 05:57:40PM +0200, Jan Beulich wrote:
> 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-u
On 27.09.2023 16:05, Roger Pau Monné wrote:
> On Wed, Sep 27, 2023 at 02:06:47PM +0200, Jan Beulich wrote:
>> On 27.09.2023 13:08, Roger Pau Monné wrote:
>>> On Wed, May 03, 2023 at 05:56:46PM +0200, Jan Beulich wrote:
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.
Make function declarations and definitions consistent.
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/domain_page.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain
On Wed, May 03, 2023 at 05:57:09PM +0200, Jan Beulich wrote:
> 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
On September 26, 2023 1:10:51 AM PDT, Nikolay Borisov
wrote:
>
>
>On 23.09.23 г. 12:41 ч., Xin Li wrote:
>> Intel VT-x classifies events into eight different types, which is
>> inherited by FRED for event identification. As such, event type
>> becomes a common x86 concept, and should be defined i
flight 183185 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183185/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183175
test-amd64-i386-xl-qemuu-win7-amd64
On Wed, Sep 27, 2023 at 1:29 AM Stefano Stabellini
wrote:
>
> From: Stefano Stabellini
>
> The feature is not commonly used, and we don't have hardware to test it,
> not in OSSTest, not in Gitlab, and not even ad-hoc manually by community
> members. We could use QEMU to test it, but even that it
flight 183193 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183193/
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 Wed, Sep 27, 2023 at 3:34?AM Jan Kara wrote:
>
> Hello,
>
> this is a v3 of the patch series which implements the idea of
> blkdev_get_by_*()
v4?
> calls returning bdev_handle which is then passed to blkdev_put() [1]. This
> makes the get and put calls for bdevs more obviously matching and a
On Wed, Sep 27, 2023 at 02:06:47PM +0200, Jan Beulich wrote:
> On 27.09.2023 13:08, Roger Pau Monné wrote:
> > On Wed, May 03, 2023 at 05:56:46PM +0200, Jan Beulich wrote:
> >> In preparation of the introduction of new vCPU operations allowing to
> >> register the respective areas (one of the two i
This serie aims to add more modularity to some feature that can be excluded
without issues from the build.
The first patch is already reviewed.
v2 update: So I've tried to see how to put the dom0less code in the common code,
but the amount of modifications are not trivial, even putting only the c
Move static memory and static shared memory code in separate modules
so that they are included only when the corresponding feature is
enabled, doing that we modularise the features and we remove some
ifdefs from the code to improve readability.
Move process_shm_node function from bootfdt module an
The 'enum domain_type' is defined by 'asm/domain.h' which is not
included (directly or indirectly) by 'asm/kernel.h'.
This currently doesn't break the compilation because asm/domain.h will
included by the user of 'kernel.h'. But it would be better to avoid
relying on it. So add the include in 'asm
Introduce a Kconfig for the dom0less feature, enabled by default,
to be able to choose if the feature should be compiled or not.
Provide static inline stubs when the option is disabled for the
functions externally visible.
Use the new Kconfig to remove dom0less DT binding from the efi-boot.h
code
Introduce Kconfig GICV2 to be able to compile the GICv2 driver only
when needed, the option is active by default.
Introduce Kconfig VGICV2 that compiles the Generic Interrupt
Controller v2 emulation for domains, it is required only when using
GICv2 driver, otherwise using the GICv3 driver it is op
Currently the dom0less feature code is mostly inside domain_build.c
and setup.c, it is a feature that may not be useful to everyone so
put the code in a different compilation module in order to make it
easier to disable the feature in the future.
Move gic_interrupt_t in domain_build.h to use it wi
On Wed, Sep 27, 2023 at 07:43:26AM -0400, Tamas K Lengyel wrote:
> On Wed, Sep 27, 2023 at 7:08 AM Roger Pau Monné wrote:
> >
> > On Wed, May 03, 2023 at 05:56:46PM +0200, Jan Beulich wrote:
> > > In preparation of the introduction of new vCPU operations allowing to
> > > register the respective a
On 27/09/2023 11:52, 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
---
Changes in v2:
- removed useless make flags
---
automation/
Hi Dan,
Thanks for the report.
On 26/09/2023 20:41, Driscoll, Dan wrote:
First off - sorry for the very long email, but there are a lot of
details related to this topic and I figured more details might be better than
less but I could be wrong here
Within Siemens Embedded,
Hi Julien,
On 27/09/2023 13:01, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 26/09/2023 09:36, Michal Orzel wrote:
>> On 26/09/2023 07:33, Leo Yan wrote:
>>>
>>>
>>> During the Linux kernel booting, an error is reported by the Xen
>>> hypervisor:
>>>
>>>(XEN) arch/arm/p2m.c:2202: d0v0: Faili
On 27.09.2023 13:08, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:56:46PM +0200, Jan Beulich wrote:
>> 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
On 27.09.2023 12:50, Roger Pau Monné wrote:
> On Wed, Sep 27, 2023 at 12:46:07PM +0200, Jan Beulich wrote:
>> On 27.09.2023 12:42, Roger Pau Monné wrote:
>>> On Wed, Sep 27, 2023 at 11:55:19AM +0200, Jan Beulich wrote:
On 27.09.2023 10:51, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 0
> On 27 Sep 2023, at 09:35, Bertrand Marquis wrote:
>
> Hi Jan,
>
>> On 27 Sep 2023, at 10:23, Jan Beulich wrote:
>>
>> On 27.09.2023 10:14, Bertrand Marquis wrote:
On 27 Sep 2023, at 09:53, Nicola Vetrini
wrote:
My opinion is that it's far easier for this to be an eclair co
On Wed, May 03, 2023 at 05:56:46PM +0200, Jan Beulich wrote:
> 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 f
Hi Michal,
On 26/09/2023 09:36, Michal Orzel wrote:
On 26/09/2023 07:33, Leo Yan wrote:
During the Linux kernel booting, an error is reported by the Xen
hypervisor:
(XEN) arch/arm/p2m.c:2202: d0v0: Failing to acquire the MFN 0x1a02dc
The kernel attempts to use an invalid memory frame num
On Wed, Sep 27, 2023 at 12:46:07PM +0200, Jan Beulich wrote:
> On 27.09.2023 12:42, Roger Pau Monné wrote:
> > On Wed, Sep 27, 2023 at 11:55:19AM +0200, Jan Beulich wrote:
> >> On 27.09.2023 10:51, Roger Pau Monné wrote:
> >>> On Wed, May 03, 2023 at 05:54:47PM +0200, Jan Beulich wrote:
> +{
>
Hi Leo,
Adding some comments on top of what already said.
On 26/09/2023 06:33, Leo Yan wrote:
+static bool __init memory_node_is_available(const void *fdt, unsigned long
node)
+{
+const char *status = fdt_getprop(fdt, node, "status", NULL);
+
+if (!status)
+return true;
+
We
On 27.09.2023 12:42, Roger Pau Monné wrote:
> On Wed, Sep 27, 2023 at 11:55:19AM +0200, Jan Beulich wrote:
>> On 27.09.2023 10:51, Roger Pau Monné wrote:
>>> On Wed, May 03, 2023 at 05:54:47PM +0200, Jan Beulich wrote:
>>> I guess we should also zap the runstate handlers, or else we might
>>> corru
[1] specifies a long list of instructions which are intended to exhibit
timing behavior independent of the data they operate on. On certain
hardware this independence is optional, controlled by a bit in a new
MSR. Provide a command line option to control the mode Xen and its
guests are to operate i
On Wed, Sep 27, 2023 at 11:55:19AM +0200, Jan Beulich wrote:
> On 27.09.2023 10:51, Roger Pau Monné wrote:
> > On Wed, May 03, 2023 at 05:54:47PM +0200, Jan Beulich wrote:
> > I guess we should also zap the runstate handlers, or else we might
> > corrupt guest state.
>
> So you think the guest mig
On 25/09/2023 23:19, Henry Wang wrote:
Hi Julien,
Hi Henry,
Yes, I was about to ask the same question but somehow forgot it. This is a quite
low risk patch and I think it is fine to have this in 4.18, so if the "Fixes”
tag
can be added on commit, please also add:
Release-acked-by: Henry
On Fri, Nov 18, 2022 at 04:49:23PM +0100, Marek Marczykowski-Górecki wrote:
> Linux enables MSI-X before disabling INTx, but keeps MSI-X masked until
> the table is filled. Then it disables INTx just before clearing MASKALL
> bit. Currently this approach is rejected by xen-pciback.
> According to t
On 27.09.2023 11:44, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:55:11PM +0200, Jan Beulich wrote:
>> 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
On Wed, May 03, 2023 at 05:55:52PM +0200, Jan Beulich wrote:
> 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
Hello,
It is necessary to change some structure contents from xen.
I have access to the registers.
One of them keeps the physical address of the structure.
But this physical address is valid for Dom0 only.
Dom0 kernel gets it by the call dma_alloc_coherent
A lower mentioned scheme does not work.
Hi Nicola,
> On Sep 27, 2023, at 17:52, 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.
On 27.09.2023 10:51, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:54:47PM +0200, Jan Beulich wrote:
>> 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 domai
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: Nicol
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 do
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 n
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 v2:
- removed useless make flags
---
automation/eclair_analysis/build.sh | 6 +++---
automa
On Wed, May 03, 2023 at 05:55:11PM +0200, Jan Beulich wrote:
> 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
On 27/09/2023 09:29, David Kahurani wrote:
If XEN_NETBK_LEGACY_SLOTS_MAX and MAX_SKB_FRAGS have a difference of
more than 1, with MAX_SKB_FRAGS being the lesser value, it opens up a
path for null-dereference. It was also noted that some distributions
were modifying upstream behaviour in that dire
flight 183190 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183190/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ad1c0394b1770315099e511de7c88a04d7af76f2
baseline version:
ovmf be971fc302cbef8f47e26
Convert xen/blkback to use bdev_open_by_dev() and pass the
handle around.
CC: xen-devel@lists.xenproject.org
Acked-by: Christoph Hellwig
Acked-by: Christian Brauner
Signed-off-by: Jan Kara
---
drivers/block/xen-blkback/blkback.c | 4 +--
drivers/block/xen-blkback/common.h | 4 +--
drivers/b
On Wed, May 03, 2023 at 05:54:47PM +0200, Jan Beulich wrote:
> 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
flight 183183 linux-5.4 real [real]
flight 183191 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183183/
http://logs.test-lab.xenproject.org/osstest/logs/183191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
Hi Federico,
> On Sep 27, 2023, at 16:41, Federico Serafini
> wrote:
>
> Make function declarations and definitions consistent.
> No functional change.
>
> Signed-off-by: Federico Serafini
This looks like a harmless change so with proper review:
Release-acked-by: Henry Wang
Kind regards,
Make function declarations and definitions consistent.
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/include/asm/mem_access.h | 2 +-
xen/arch/x86/mm/mem_access.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/include/asm/
Hi Jan,
> On 27 Sep 2023, at 10:23, Jan Beulich wrote:
>
> On 27.09.2023 10:14, Bertrand Marquis wrote:
>>> On 27 Sep 2023, at 09:53, Nicola Vetrini wrote:
>>> My opinion is that it's far easier for this to be an eclair configuration
>>> (which has the
>>> advantage not to depend on the exact
If XEN_NETBK_LEGACY_SLOTS_MAX and MAX_SKB_FRAGS have a difference of
more than 1, with MAX_SKB_FRAGS being the lesser value, it opens up a
path for null-dereference. It was also noted that some distributions
were modifying upstream behaviour in that direction which necessitates
this patch.
Signed-
On 27.09.2023 10:14, Bertrand Marquis wrote:
>> On 27 Sep 2023, at 09:53, Nicola Vetrini wrote:
>> My opinion is that it's far easier for this to be an eclair configuration
>> (which has the
>> advantage not to depend on the exact definition of unreachable) and then
>> perhaps a comment
>> above
On 15.09.2023 09:43, Roger Pau Monne wrote:
> The current logic to chose the preferred reboot method is based on the mode
> Xen
> has been booted into, so if the box is booted from UEFI, the preferred reboot
> method will be to use the ResetSystem() run time service call.
>
> However, that method
Hi Stefano,
> On 27 Sep 2023, at 03:05, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Following up from the MISRA C group discussion, add Rule 11.9 to
> docs/misra/rules.rst.
>
> Signed-off-by: Stefano Stabellini
I agree with Jan on dropping the "integer" word here.
With that
Hi,
> On 27 Sep 2023, at 09:53, Nicola Vetrini wrote:
>
>>> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
>>> > index 695d2fa1f1..2a8527cacc 100644
>>> > --- a/xen/arch/arm/psci.c
>>> > +++ b/xen/arch/arm/psci.c
>>> > @@ -59,6 +59,7 @@ void call_psci_cpu_off(void)
>>> > }
>>> >
Hi Stefano,
> On 8 Sep 2023, at 22:27, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Add 14.3, with project-wide deviations.
>
> Also take the opportunity to clarify that parameters of function pointer
> types are expected to have names (Rule 8.2).
>
> Signed-off-by: Stefano Sta
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index 695d2fa1f1..2a8527cacc 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -59,6 +59,7 @@ void call_psci_cpu_off(void)
> }
> }
> +/* SAF-2-safe */
I think any use of SAF-2-safe should be accompanied with an
On 08.09.2023 22:27, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Add 14.3, with project-wide deviations.
>
> Also take the opportunity to clarify that parameters of function pointer
> types are expected to have names (Rule 8.2).
>
> Signed-off-by: Stefano Stabellini
I'm not overl
On 27.09.2023 08:32, Jan Beulich wrote:
> On 27.09.2023 00:37, Shawn Anastasio wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -1211,6 +1211,14 @@ static unsigned int node_to_scrub(bool get_node)
>> } while ( !cpumask_empty(&node_to_cpumask(node)) &&
>>
88 matches
Mail list logo
