flight 170252 linux-linus real [real]
flight 170262 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170252/
http://logs.test-lab.xenproject.org/osstest/logs/170262/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On 08/05/2022 11:34, Bernhard Beschow wrote:
This function was declared in a generic and public header, implemented
in a device-specific source file but only used in xen_platform. Given its
'aux' parameter, this function is more xen-specific than piix-specific.
Also, the hardcoded magic constants
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, docs/support-matrix-generate throw an error for it:
Generating support matrix (origin/stable-NN )
+ docs/support-ma
On Thu, May 05, 2022 at 10:16:22AM +0200, Juergen Gross wrote:
> Instead of using a private macro for an invalid grant reference use
> the common one.
>
> Signed-off-by: Juergen Gross
Acked-by: Roger Pau Monné
Thanks, Roger.
On Thu, May 05, 2022 at 10:16:32AM +0200, Juergen Gross wrote:
> Simplify blkfront's ring creation and removal via xenbus_setup_ring()
> and xenbus_teardown_ring().
>
> Signed-off-by: Juergen Gross
Acked-by: Roger Pau Monné
Thanks, Roger.
> 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, docs/support-matrix-generate throw an error for it:
>
>
On 05.05.22 11:16, Juergen Gross wrote:
Hello Juergen
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross
---
V3:
- terminate grant ref list with 0 (Oleksandr Tyshchenko)
Reviewed-by: Oleksandr Tyshchenko
---
drivers/xe
On Wed, Apr 27, 2022 at 05:38:12PM +0100, Ross Lagerwall via wrote:
> The BAR emulated register definition does not set emu_mask because it
> varies depending on bar_flag. If emu_mask is not set, then the BAR is
> initialized based on the host value which causes the BAR to be initially
> mapped at
Hi Stefano,
> 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 ECLAIR in action", then you can select "Show 100 entr
flight 170261 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170261/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Am 9. Mai 2022 08:02:13 UTC schrieb "Durrant, Paul" :
>On 08/05/2022 11:34, Bernhard Beschow wrote:
>> This function was declared in a generic and public header, implemented
>> in a device-specific source file but only used in xen_platform. Given its
>> 'aux' parameter, this function is more xen-sp
Hi Julien,
> On 4 May 2022, at 09:06, Julien Grall wrote:
>
>
>
> On 04/05/2022 08:24, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 3 May 2022, at 19:47, Julien Grall wrote:
A new cpuerrata capability is introduced to enable the alternative
>>>
>>> 'sb' is definitel
flight 170263 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170263/
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 Fri, May 06, 2022 at 02:15:47PM +0200, Jan Beulich wrote:
> On 03.05.2022 10:26, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/cpuid.c
> > +++ b/xen/arch/x86/cpuid.c
> > @@ -541,6 +541,9 @@ static void __init calculate_hvm_max_policy(void)
> > raw_cpuid_policy.basic.sep )
> >
On 09/05/2022 11:08, Bertrand Marquis wrote:
Hi Julien,
Hi,
On 4 May 2022, at 09:06, Julien Grall wrote:
On 04/05/2022 08:24, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 3 May 2022, at 19:47, Julien Grall wrote:
A new cpuerrata capability is introduced to enable the alter
flight 170256 qemu-mainline real [real]
flight 170265 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170256/
http://logs.test-lab.xenproject.org/osstest/logs/170265/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Hi Julien,,
> On 9 May 2022, at 11:31, Julien Grall wrote:
>
>
>
> On 09/05/2022 11:08, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi,
>
>>> On 4 May 2022, at 09:06, Julien Grall wrote:
>>>
>>>
>>>
>>> On 04/05/2022 08:24, Bertrand Marquis wrote:
Hi Julien,
>>>
>>> Hi Bertrand,
>>>
Hi,
On 09/05/2022 11:49, Bertrand Marquis wrote:
On 9 May 2022, at 11:31, Julien Grall wrote:
On 09/05/2022 11:08, Bertrand Marquis wrote:
On 4 May 2022, at 09:06, Julien Grall wrote:
On 04/05/2022 08:24, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 3 May 2022, at 19:47, Julien
flight 170266 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170266/
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 10:39:32AM +, Ross Lagerwall wrote:
> > From: Roger Pau Monne
> > Sent: Monday, May 9, 2022 10:28 AM
> > To: Ross Lagerwall
> > Cc: xen-devel@lists.xenproject.org ;
> > Stefano Stabellini ; Anthony Perard
> > ; Paul Durrant ;
> > qemu-de...@nongnu.org
> > Subject:
flight 170257 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170257/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw broken
Tests which are fail
Hi,
> On 9 May 2022, at 12:08, Julien Grall wrote:
>
> Hi,
>
> On 09/05/2022 11:49, Bertrand Marquis wrote:
>>> On 9 May 2022, at 11:31, Julien Grall wrote:
>>> On 09/05/2022 11:08, Bertrand Marquis wrote:
> On 4 May 2022, at 09:06, Julien Grall wrote:
>
>
>
> On 04/05/
On May 4, 2022 5:57:02 PM GMT+02:00, Juergen Gross wrote:
>Add a simple infrastructure for setting, resetting and querying
>platform feature flags.
>
>Flags can be either global or architecture specific.
>
>Signed-off-by: Juergen Gross
>---
>V2:
>- rename set/reset functions to platform_[set|c
On May 4, 2022 3:57:03 PM UTC, Juergen Gross wrote:
>Instead of using arch_has_restricted_virtio_memory_access() together
>with CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, replace those
>with platform_has() and a new platform feature
>PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS.
>
>Signed-off-by
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
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 +
xen/arch/x86/mm/
'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
sh_emulate_ma
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 a/xen/arch/
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 differen
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
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
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 "crash_kexec_post_
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
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
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,
Guilherm
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 disa
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 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 a
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 t
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 St
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 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. I
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 WARNI
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 u
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 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 the
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 hardcod
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 DEPRE
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 19
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
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
> 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 diffe
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 Wed,
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?
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
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 co
On 09/05/2022 13:14, Suzuki K Poulose wrote:
> [...]>
> I have queued this to coresight/next.
>
> Thanks
> Suzuki
Thanks a lot Suzuki!
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, Baoquan
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
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, docs/support-matrix-ge
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 reporte
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 @@
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 acros
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
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 0
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 is
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 this
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 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 patc
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 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 ECLA
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 xen-deve
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 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 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.
>
> Al
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 by
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 correspondi
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
> e
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 1
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 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 saver
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. Th
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 a/include
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 ++
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 cha
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 same
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 fil
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
--
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 i
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
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
Signed
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 Osi
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 Osi
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.
Acked-by: Helge Deller # parisc
Reviewed-by: Michał Mi
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
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
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.
Signed-off-
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
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 s
1 - 100 of 136 matches
Mail list logo
