flight 170285 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170280 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170280/
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
When static domain populates memory through populate_physmap on runtime,
other than allocating from heap, it shall retrieve reserved pages from
resv_page_list to make sure that guest RAM is still restricted in statically
configured memory regions. And this commit introduces a new helper
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_using_staticmem() to tell.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v4 changes:
- no changes
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
---
v4 changes:
-
The code in free_heap_pages() will try to merge pages with the
successor/predecessor if pages are suitably aligned. So if the pages
reserved are right next to the pages given to the heap allocator,
free_heap_pages() will merge them, and give the reserved pages to heap
allocator accidently as a
Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
free_staticmem_pages will be called by free_heap_pages in runtime
for static domain
Today when a domain unpopulates the memory on runtime, they will always
hand the memory over to the heap allocator. And it will be a problem if it
is a static domain.
Pages used as guest RAM for static domain shall always be reserved to this
domain only, and not be used for any other purposes, so
flight 170275 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170275/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170256
test-armhf-armhf-libvirt 16
flight 170284 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170284/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Tue, 3 May 2022, Bertrand Marquis wrote:
> Sync arm64 sysreg bit shift definitions with status of Linux kernel as
> of 5.18-rc3 version (linux commit b2d229d4ddb1).
> Sync ID registers sanitization with the status of Linux 5.18-rc3 and add
> sanitization of ISAR2 registers.
> Complete AA64ISAR2
On Wed, 4 May 2022, Julien Grall wrote:
> > Do I understand right that it is ok for you if I push one patch mentioning
> > all the commits done in Linux corresponding to the changes (instead of one
> > patch per commit) ?
>
> For this case yes.
I managed to do a review of the patch by doing a
flight 170283 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170282 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170282/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Use devm_register_sys_off_handler() that replaces global
pm_power_off_prepare variable and allows to register multiple
power-off handlers.
Acked-by: Mark Brown
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/pfuze100-regulator.c | 42 +++---
1 file changed, 17
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Catalin Marinas
Reviewed-by: Michał
All pm_power_off_prepare() users were converted to sys-off handler API.
Remove the obsolete global callback variable.
Signed-off-by: Dmitry Osipenko
---
include/linux/pm.h | 1 -
kernel/reboot.c| 19 ---
2 files changed, 20 deletions(-)
diff --git a/include/linux/pm.h
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Reviewed-by: Michał Mirosław
Signed-off-by: Dmitry
Add devm_register_power_off_handler() helper that registers sys-off
handler using power-off mode and with a default priority. Most drivers
will want to register power-off handler with a default priority, so this
helper will reduce the boilerplate code and make code easier to read and
follow.
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Michael Ellerman
Reviewed-by: Michał
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Reviewed-by: Russell King (Oracle)
Reviewed-by:
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Thomas Bogendoerfer
Reviewed-by: Michał
Nexus 7 Android tablet can be turned off using a special bootloader
command which is conveyed to bootloader by putting magic value into the
special scratch register and then rebooting normally. This power-off
method should be invoked if USB cable is connected. Bootloader then will
display battery
Replace legacy pm_power_off with kernel_can_power_off() helper that
is aware about chained power-off handlers.
Acked-by: Krzysztof Kozlowski
Reviewed-by: Michał Mirosław
Signed-off-by: Dmitry Osipenko
---
drivers/memory/emif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Juergen Gross
Reviewed-by: Michał Mirosław
Add devm_register_restart_handler() helper that registers sys-off
handler using restart mode and with a default priority. Most drivers
will want to register restart handler with a default priority, so this
helper will reduce the boilerplate code and make code easier to read and
follow.
Switch to sys-off API that replaces legacy pm_power_off callbacks,
allowing us to remove global pm_* variables and support chaining of
all restart and power-off modes consistently.
Signed-off-by: Dmitry Osipenko
---
drivers/acpi/sleep.c | 16
1 file changed, 12 insertions(+), 4
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Palmer Dabbelt
Reviewed-by: Michał Mirosław
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Helge Deller # parisc
Reviewed-by: Michał
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Reviewed-by: Michał Mirosław
Signed-off-by: Dmitry
Kernel now supports chained power-off handlers. Use
register_power_off_handler() that registers power-off handlers and
do_kernel_power_off() that invokes chained power-off handlers. Legacy
pm_power_off() will be removed once all drivers will be converted to
the new sys-off API.
Normally arch code
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Reviewed-by: Michał Mirosław
Signed-off-by: Dmitry
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Guo Ren
Reviewed-by: Michał Mirosław
Add platform-level registration helpers that will ease transition of the
arch/platform power-off callbacks to the new sys-off based API, allowing
us to remove the global pm_power_off variable in the future.
Signed-off-by: Dmitry Osipenko
---
include/linux/reboot.h | 3 +++
kernel/reboot.c
Add weak stub for the global pm_power_off callback variable. This will
allow us to remove pm_power_off definitions from arch/ code and transition
to the new sys-off based API that will replace the global variable.
Signed-off-by: Dmitry Osipenko
---
kernel/reboot.c | 6 ++
1 file changed, 6
Add do_kernel_power_off() helper that will remove open-coded pm_power_off
invocations from the architecture code. This is the first step on the way
to remove the global pm_power_off variable, which will allow us to
implement consistent power-off chaining support.
Signed-off-by: Dmitry Osipenko
Wrap legacy power-off callbacks into sys-off handlers in order to
support co-existence of both legacy and new callbacks while we're
in process of upgrading legacy callbacks to the new API.
Signed-off-by: Dmitry Osipenko
---
kernel/reboot.c | 44 ++--
1
In order to support power-off chaining we need to get rid of the global
pm_* variables, replacing them with the new kernel API functions that
support chaining.
Introduce new generic sys-off handler API that brings the following
features:
1. Power-off and restart handlers are registered using
Add kernel_can_power_off() helper that replaces open-coded checks of
the global pm_power_off variable. This is a necessary step towards
supporting chained power-off handlers.
Signed-off-by: Dmitry Osipenko
---
include/linux/reboot.h | 1 +
kernel/reboot.c| 14 +-
2 files
Add atomic_notifier_call_chain_is_empty() that returns true if given
atomic call chain is empty.
Reviewed-by: Michał Mirosław
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 2 ++
kernel/notifier.c| 13 +
2 files changed, 15 insertions(+)
diff --git
Add variant of blocking/atomic_notifier_chain_register() functions that
allow registration of a notifier only if it has unique priority, otherwise
-EBUSY error code is returned by the new functions.
Reviewed-by: Michał Mirosław
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 5
Problem
---
SoC devices require power-off call chaining functionality from kernel.
We have a widely used restart chaining provided by restart notifier API,
but nothing for power-off.
Solution
Introduce new API that provides call chains support for all restart and
power-off modes.
flight 170273 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170273/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170252
test-armhf-armhf-libvirt 16
flight 170279 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170278 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170278/
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 Sat, 7 May 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> This binding indicates that Xen grant mappings scheme needs to be
>
On Sat, 7 May 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Use the presence of recently introduced "xen,dev-domid" property
> in the device node as a clear indicator of enabling Xen grant
> mappings scheme for that device and read the ID of Xen domain where
> the
On Sat, 7 May 2022, Oleksandr Tyshchenko wrote:
> From: Juergen Gross
>
> Introduce Xen grant DMA-mapping layer which contains special DMA-mapping
> routines for providing grant references as DMA addresses to be used by
> frontends (e.g. virtio) in Xen guests.
>
> Add the needed functionality
On Sat, 7 May 2022, Oleksandr Tyshchenko wrote:
> From: Juergen Gross
>
> In order to support virtio in Xen guests add a config option XEN_VIRTIO
> enabling the user to specify whether in all Xen guests virtio should
> be able to access memory via Xen grant mappings only on the host side.
>
>
On Wed, 4 May 2022, Rahul Singh wrote:
> This patch introduces a new feature to support the signaling between
> two domains in dom0less system.
>
> Signed-off-by: Rahul Singh
> ---
> v2 changes:
> - switch to the one-subnode-per-evtchn under xen,domain" compatible node.
> - Add more detail about
On Fri, 6 May 2022, Luca Fancellu wrote:
> *** Resending the serie adding the maintainers ***
> *** Patches #4 and #6 needs a review from the maintainer of that area ***
Committed, thanks!
On 09/05/2022 20:29, Andrew Cooper wrote:
> On 09/05/2022 20:01, Stefano Stabellini wrote:
>> On Mon, 9 May 2022, Juergen Gross wrote:
>>> On IRC the question came up whether it would be possible to have a
>>> special marker for Linux patches on the xen-devel ML.
>>>
>>> I suggested to use
On Mon, 9 May 2022, Bertrand Marquis wrote:
> > On 6 May 2022, at 17:31, Stefano Stabellini wrote:
> >
> > Hi all,
> >
> > Roberto kindly provided the ECLAIR x86 results:
> >
> > https://eclairit.com:8443/job/XEN/Target=X86_64,agent=public/lastSuccessfulBuild/eclair/
> >
> > Click on "See
flight 170277 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 5/9/22 3:01 PM, Stefano Stabellini wrote:
On Mon, 9 May 2022, Juergen Gross wrote:
On IRC the question came up whether it would be possible to have a
special marker for Linux patches on the xen-devel ML.
I suggested to use xen-devel+li...@lists.xenprojext.org for those
patches. With a
On Sat, 7 May 2022, Penny Zheng wrote:
> > On Fri, 6 May 2022, Penny Zheng wrote:
> > > Later, we need to add the right amount of references, which should be
> > > the number of borrower domains, to the owner domain. Since we only
> > > have
> > > get_page() to increment the page reference by 1, a
On Mon, 9 May 2022, Juergen Gross wrote:
> On IRC the question came up whether it would be possible to have a
> special marker for Linux patches on the xen-devel ML.
>
> I suggested to use xen-devel+li...@lists.xenprojext.org for those
> patches. With a patch for the kernel's MAINTAINERS file
Hi Daniel,
On 03/05/2022 12:17, Daniel P. Smith wrote:
There are new capabilities, dom0less and hyperlaunch, that introduce internal
hypervisor logic which needs to make resource allocation calls that are
protected by XSM access checks. This creates an issue as a subset of the
hypervisor code
On 03/05/2022 14:17, Luca Fancellu wrote:
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0bf63ffa84..b93101191e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -186,6 +186,28 @@ static int cf_check flask_domain_alloc_security(struct
domain *d)
return
flight 170276 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Alex,
On 28/04/2022 11:34, Alex Bennée wrote:
When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
kernels had a bug where the physical address was copied directly from
ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits
the same error by blindly copying
Hi,
On 26/04/2022 13:38, Bertrand Marquis wrote:
diff --git a/xen/arch/arm/include/asm/processor.h
b/xen/arch/arm/include/asm/processor.h
index 852b5f3c24..ef37cfa16f 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -219,9 +219,11 @@
On 06/05/2022 12:28, Bertrand Marquis wrote:
On 4 May 2022, at 18:15, Rahul Singh wrote:
When Xen boots on the platform that implements the GIC 600, ITS
MAPC_LPI_OFF uncorrectable command error issue is observed.
As per the GIC-600 TRM (Revision: r1p6) MAPC_LPI_OFF command error can
be
Hi,
On 09/05/2022 09:42, George Dunlap wrote:
On May 9, 2022, at 9:07 AM, Julien Grall wrote:
From: Julien Grall
Commit a5968a553f6a "SUPPORT.MD: Correct the amount of physical memory
supported for Arm" added a support statement split over two lines.
Unfortunately,
flight 170274 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170274/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hey Hatayma, thanks for your great analysis and no need for apologies!
I'll comment/respond properly inline below, just noticing here that I've
CCed Mark and Marc (from the ARM64 perspective), Michael (Hyper-V
perspective) and Hari (PowerPC perspective), besides the usual suspects
as Petr,
On 09/05/2022 13:14, Suzuki K Poulose wrote:
> [...]>
> I have queued this to coresight/next.
>
> Thanks
> Suzuki
Thanks a lot Suzuki!
Hi
On 09/05/2022 14:09, Guilherme G. Piccoli wrote:
On 28/04/2022 05:11, Suzuki K Poulose wrote:
Hi Guilherme,
On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
The panic notifier infrastructure executes registered callbacks when
a panic event happens - such callbacks are executed in atomic
flight 170272 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170272/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On IRC the question came up whether it would be possible to have a
special marker for Linux patches on the xen-devel ML.
I suggested to use xen-devel+li...@lists.xenprojext.org for those
patches. With a patch for the kernel's MAINTAINERS file this would
be quite easy to achieve.
Any thoughts?
I find the shortlog to be very confusing, the bug has nothing to do with
disabling
VMX and I distinctly remember wrapping VMXOFF with exception fixup to prevent
doom
if VMX is already disabled :-). The issue is really that nmi_shootdown_cpus()
doesn't
play nice with being called twice.
On
> On May 6, 2022, at 1:00 PM, Luca Fancellu wrote:
>
> Introduce a way to create different cpupools at boot time, this is
> particularly useful on ARM big.LITTLE system where there might be the
> need to have different cpupools for each type of core, but also
> systems using NUMA can have
Sorry for the delayed response. Unfortunately, I had 10 days holidays
until yesterday...
> .../admin-guide/kernel-parameters.txt | 42 ++-
> include/linux/panic_notifier.h| 1 +
> kernel/kexec_core.c | 8 +-
> kernel/panic.c
flight 170271 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170271/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170264 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170264/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169782
test-amd64-amd64-xl-qemut-win7-amd64
On 29/04/2022 13:04, Guilherme G. Piccoli wrote:
> On 27/04/2022 21:28, Randy Dunlap wrote:
>>
>>
>> On 4/27/22 15:49, Guilherme G. Piccoli wrote:
>>> + crash_kexec_post_notifiers
>>> + This was DEPRECATED - users should always prefer the
>>
>> This is
On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> Currently we have 3 notifier lists in the panic path, which will
> be wired in a way to allow the notifier callbacks to run in
> different moments at panic time, in a subsequent patch.
>
> But there is also an odd set of architecture calls
On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> The alpha panic notifier has some code issues, not following
> the conventions of other notifiers. Also, it might halt the
> machine but still it is set to run as early as possible, which
> doesn't seem to be a good idea.
>
> This patch cleans
flight 170270 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Mon, May 09, 2022 at 01:24:09PM +0100, Andrew Cooper wrote:
> This is undefined behaviour, because there is no _spin_lock_cb() in a separate
> translation unit (C11 6.7.4.11).
>
> Moreover, MISRA prohibits this construct because, in the case where it is well
> defined, the compiler is free to
From: Oleksandr Tyshchenko
With Xen PV Display driver in use the "expected" VM_DONTEXPAND flag
is not set (neither explicitly nor implicitly), so the driver hits
the code path in drm_gem_mmap_obj() which triggers the WARNING.
Signed-off-by: Oleksandr Tyshchenko
---
This patch eliminates a
On 2022-04-27 17:12, Rahul Singh wrote:
Xen should control the SMMUv3 devices therefore, don't expose the
SMMUv3 devices to dom0. Deny iomem access to SMMUv3 address space for
dom0 and also make ACPI IORT SMMUv3 node type to 0xff.
...making the resulting IORT technically useless to consumers.
flight 170269 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170269/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 09/05/2022 14:18, Roger Pau Monné wrote:
> On Mon, May 09, 2022 at 01:24:07PM +0100, Andrew Cooper wrote:
>> Spotted by Eclair MISRA scanner.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Roger Pau Monné
>
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>> CC: Wei Liu
>> CC: Stefano
On 05.05.22 11:16, Juergen Gross wrote:
Hello Juergen.
Many Xen PV frontends share similar code for setting up a ring page
(allocating and granting access for the backend) and for tearing it
down.
Create new service functions doing all needed steps in one go.
This requires all frontends
On Mon, May 09, 2022 at 01:24:08PM +0100, Andrew Cooper wrote:
> 'int' bitfields in particular have implementation defined behaviour under gcc
> and can change signed-ness with -funsigned-bitfields.
>
> There is no need for low_bit_was_clear to be a bitfield in the first place; it
> is only used
On Mon, May 09, 2022 at 01:24:07PM +0100, Andrew Cooper wrote:
> Spotted by Eclair MISRA scanner.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> CC: Stefano Stabellini
> CC: Julien Grall
> CC: Volodymyr Babchuk
On 28/04/2022 05:11, Suzuki K Poulose wrote:
> Hi Guilherme,
>
> On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
>> The panic notifier infrastructure executes registered callbacks when
>> a panic event happens - such callbacks are executed in atomic context,
>> with interrupts and preemption
On 05/05/2022 15:55, Hari Bathini wrote:
> [...]
> The change looks good. I have tested it on an LPAR (ppc64).
>
> Reviewed-by: Hari Bathini
>
Hi Michael. do you think it's possible to add this one to powerpc/next
(or something like that), or do you prefer a V2 with his tag?
Thanks,
Hi Andrew,
> On 9 May 2022, at 13:24, Andrew Cooper wrote:
>
> 'int' bitfields in particular have implementation defined behaviour under gcc
> and can change signed-ness with -funsigned-bitfields.
>
> There is no need for low_bit_was_clear to be a bitfield in the first place; it
> is only used
Hi Andrew,
> On 9 May 2022, at 13:24, Andrew Cooper wrote:
>
> This is undefined behaviour, because there is no _spin_lock_cb() in a separate
> translation unit (C11 6.7.4.11).
>
> Moreover, MISRA prohibits this construct because, in the case where it is well
> defined, the compiler is free to
On 27/04/2022 19:48, Guilherme G. Piccoli wrote:
> In the panic path we have a list of functions to be called, the panic
> notifiers - such callbacks perform various actions in the machine's
> last breath, and sometimes users want them to run before kdump. We
> have the parameter
Hi Andrew,
> On 9 May 2022, at 13:24, Andrew Cooper wrote:
>
> Spotted by Eclair MISRA scanner.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
flight 170268 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170268/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
'int' bitfields in particular have implementation defined behaviour under gcc
and can change signed-ness with -funsigned-bitfields.
There is no need for low_bit_was_clear to be a bitfield in the first place; it
is only used as a boolean. Doing so even improves the code generation in
Spotted by Eclair MISRA scanner.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
---
xen/arch/x86/mm/p2m.h | 5 +
1 file changed, 5 insertions(+)
diff --git
This is undefined behaviour, because there is no _spin_lock_cb() in a separate
translation unit (C11 6.7.4.11).
Moreover, MISRA prohibits this construct because, in the case where it is well
defined, the compiler is free to use either implementation and nothing
prevents the two from being
Trivial fixes for MISRA issues while idly looking through the x86 report.
Andrew Cooper (3):
x86/p2m.h: Add include guards
x86/shadow: Don't use signed bitfield in sh_emulate_ctxt
common/spinlock: Drop inline from _spin_lock_cb()
xen/arch/x86/mm/p2m.h| 5 +
flight 170267 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170267/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
1 - 100 of 127 matches
Mail list logo
