On 10/27/21 23:16, Dmitry Osipenko wrote:
> 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 power-off API.
>
>
Hi all,
After merging the xen-tip tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
vmlinux.o: warning: objtool: pv_ops[32]: paravirt_BUG
vmlinux.o: warning: objtool: lock_is_held_type()+0x145: call to pv_ops[32]()
leaves .noinstr.text section
Presuambly introduced b
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/irq.c
between commits:
20125c872a3f ("x86/xen: Make save_fl() noinstr")
d7bfc7d57cbe ("x86/xen: Make irq_enable() noinstr")
09c413071e2d ("x86/xen: Make irq_disable() noinstr")
1462eb381b4c ("x86/xen:
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be used by other architectures, e.g. Arm.
Currently PCI backend implements multiple functionalities at a time,
such as:
1. It is used as a database for assignable PCI devices, e.g. xl
pci-a
flight 165916 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165916/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165885
test-armhf-armhf-libvirt 16 saver
On Wed, 27 Oct 2021 14:16:48 PDT (-0700), dig...@gmail.com wrote:
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 p
flight 165893 linux-5.4 real [real]
flight 165918 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165893/
http://logs.test-lab.xenproject.org/osstest/logs/165918/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armh
On Tue, 26 Oct 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch implements arch_xen_unpopulated_init() on Arm where
> the extended regions (if any) are gathered from DT and inserted
> into passed Xen resource to be used as unused address space
> for Xen scratch pages
On Tue, 26 Oct 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Read the start address of the grant table space from DT
> (region 0).
>
> This patch mostly restores behaviour before commit 3cf4095d7446
> ("arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table")
> but
The sched_clock() can be used very early since
commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition,
with commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock time from
0"), kdump kernel in Xen HVM guest may panic at very early stage when
accessing &__this_cpu_read(xen_v
On Thu, 28 Oct 2021, Julien Grall wrote:
> On Thu, 28 Oct 2021, 00:14 Stefano Stabellini, wrote:
> On Wed, 27 Oct 2021, Julien Grall wrote:
> > > > > > + return ret;
> > > > > > }
> > > > > > static int register_smmu_master(struct arm_smmu_device
> *smmu,
>
On Wed, 27 Oct 2021, Julien Grall wrote:
> Hi Oleksandr,
>
> On 27/10/2021 09:37, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko
> >
> > If a PCI host bridge device is present in the device tree, but is
> > disabled, then its PCI host bridge driver was not instantiated.
> > Thi
On Thu, 28 Oct 2021, 00:43 Julien Grall, wrote:
>
>
> On Thu, 28 Oct 2021, 00:14 Stefano Stabellini,
> wrote:
>
>> On Wed, 27 Oct 2021, Julien Grall wrote:
>> > > > > > +return ret;
>> > > > > >}
>> > > > > >static int register_smmu_master(struct arm_smmu_device *smmu,
>> > > > > > @
On Thu, 28 Oct 2021, 00:14 Stefano Stabellini,
wrote:
> On Wed, 27 Oct 2021, Julien Grall wrote:
> > > > > > +return ret;
> > > > > >}
> > > > > >static int register_smmu_master(struct arm_smmu_device *smmu,
> > > > > > @@ -2056,7 +2066,10 @@ static int arm_smmu_add_device(struct
> de
On Wed, 27 Oct 2021, Anthony PERARD wrote:
> On Mon, Oct 25, 2021 at 06:42:00PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Introduce a test based on QEMU to run Xen, Dom0 and start a DomU.
> > This is similar to the existing qemu-alpine-arm64.sh script and test.
> > The
On Wed, 27 Oct 2021, Stefano Stabellini wrote:
> On Wed, 27 Oct 2021, Juergen Gross wrote:
> > On 26.10.21 02:54, Stefano Stabellini wrote:
> > > On Mon, 25 Oct 2021, Juergen Gross wrote:
> > > > On 22.10.21 21:41, Stefano Stabellini wrote:
> > > > > +Juergen
> > > > >
> > > > > On Fri, 22 Oct 202
On Wed, 27 Oct 2021, Julien Grall wrote:
> > > > > + return ret;
> > > > > }
> > > > > static int register_smmu_master(struct arm_smmu_device *smmu,
> > > > > @@ -2056,7 +2066,10 @@ static int arm_smmu_add_device(struct device
> > > > > *dev)
> > > > > } else {
> > > > >
On Wed, 27 Oct 2021, Juergen Gross wrote:
> On 26.10.21 02:54, Stefano Stabellini wrote:
> > On Mon, 25 Oct 2021, Juergen Gross wrote:
> > > On 22.10.21 21:41, Stefano Stabellini wrote:
> > > > +Juergen
> > > >
> > > > On Fri, 22 Oct 2021, Andrew Cooper wrote:
> > > > > On 22/10/2021 00:08, Stefan
Hi,
During suspend my kernel (v5.15-rc7) tries to disable non-boot CPUs, as it
should. The first time the CPUs are offlined I get a BUG (it's WARN but it
should be BUG if it could). The second time I suspend I get a WARN.
I tried my very best to track what is happening during the first suspend
an
On Wed, 27 Oct 2021, Anthony PERARD wrote:
> > But we do have a severe problem at the moment with external sources: our
> > "git clones" keep failing during the build on x86. That is definitely
> > something worth improving (see my other email thread on the subject) and
> > it is the main problem a
Use devm_register_simple_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/palmas.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drive
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/nds32/kerne
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/mips/kernel
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/ia64/kernel
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/x86/kernel/
Switch to power-handler API that replaces legacy pm_power_off callbacks.
Signed-off-by: Dmitry Osipenko
---
drivers/acpi/sleep.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 3023224515ab..41b3ea8
Use devm_register_simple_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/tps65910.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd
Use devm_register_trivial_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/twl4030-power.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/t
Replace legacy pm_power_off with kernel_can_power_off() helper that
is aware about chained power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/memory/emif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 762d0c0f
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/parisc/kern
Use devm_register_power_handler() that replaces global pm_power_off
variable and allows to register multiple power-off handlers. It also
provides restart-handler support, i.e. all in one API.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/rn5t618.c | 56 --
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/powerpc/ker
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/csky/kernel
Use devm_register_simple_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/tps6586x.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers
Use devm_register_simple_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/rk808.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers
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 power-off API.
Normally arch cod
Use register_simple_power_off_handler() that replaces global pm_power_off
variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/axp20x.c | 22 +++---
include/linux/mfd/axp20x.h | 1 +
2 files changed, 12 insertions(+),
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/arm64/kerne
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/sh/kernel/r
Use devm_register_power_handler() that replaces global pm_power_off
variable and allows to register multiple power-off handlers. It also
provides restart-handler support, i.e. all in one API.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/acer-ec-a500.c | 52 ++---
Use devm_register_trivial_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/dm355evm_msp.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/dri
Use devm_register_simple_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/retu-mfd.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --gi
Use devm_register_simple_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/max8907.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/riscv/kerne
Use devm_register_power_handler() that replaces global pm_power_off
variable and allows to register multiple power-off handlers. It also
provides restart-handler support, i.e. all in one API.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/ntxec.c | 50 ++--
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/arm/kernel/
Nexus 7 Android tablet can be turned off using a special bootloader
command which is conveyed to bootloader by putting magic value into
specific scratch register and then rebooting normally. This power-off
method should be invoked if USB cable is connected. Bootloader then will
display battery stat
Use devm_register_power_handler() that replaces global pm_power_off_prepare
variable and allows to register multiple power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/pfuze100-regulator.c | 39 ++
1 file changed, 15 insertions(+), 24 deletions(-)
d
Use devm_register_power_handler() that replaces global pm_power_off
variable and allows to register multiple power-off handlers. It also
provides restart-handler support, i.e. all in one API.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/ene-kb3930.c | 45 ++-
Use devm_register_simple_power_off_handler() that replaces global
pm_power_off variable and allows to register multiple power-off handlers.
Nexus 7 Android tablet can be powered off using MAX77663 PMIC and using
a special bootloader command. At first the bootloader option should be
tried, it will
flight 165901 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165901/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
SoC platforms often have multiple options of how to perform system's
power-off and restart operations. Meanwhile today's kernel is limited to
a single option. Add combined power-off+restart handler call chain API,
which is inspired by the restart API. The new API provides both power-off
and restart
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 power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/x86/xen/enl
There is no need to annotate function prototypes with 'extern', it makes
code less readable. Remove unnecessary annotations from .
Signed-off-by: Dmitry Osipenko
---
include/linux/reboot.h | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git
Correct s/implemenations/implementations/ in .
Signed-off-by: Dmitry Osipenko
---
include/linux/reboot.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index af907a3d68d1..7c288013a3ca 100644
--- a/include/linux/reboot.h
+++ b/
Emit warning if unregister_restart_handler() fails since it never should
fail. This will ease further API development by catching mistakes early.
Signed-off-by: Dmitry Osipenko
---
kernel/reboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/reboot.c b/kernel/reboot
Add sanity check which ensures that there are no two restart handlers
registered with the same priority. Normally it's a direct sign of a
problem if two handlers use the same priority.
Signed-off-by: Dmitry Osipenko
---
kernel/reboot.c | 15 ++-
1 file changed, 14 insertions(+), 1 de
Add atomic/blocking_notifier_has_unique_priority() helpers which return
true if given handler has unique priority.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 5 +++
kernel/notifier.c| 74
2 files changed, 79 insertions(+)
diff
Add blocking_notifier_call_chain_empty() that returns true if call chain
is empty.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 2 ++
kernel/notifier.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include/linux/notifier.h b/include/linux/notifier.
There is no need to annotate function prototypes with 'extern', it makes
code less readable. Remove unnecessary annotations from .
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/incl
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 both restart and power-off call chains.
Why combine restar
flight 165915 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165915/
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
GCC master (nearly version 12) complains:
hvm.c: In function 'hvm_gsi_eoi':
hvm.c:905:10: error: the comparison will always evaluate as 'true' for the
address of 'dpci' will never be NULL [-Werror=address]
905 | if ( !pirq_dpci(pirq) )
| ^
In file included from /lo
branch xen-unstable
xenbranch xen-unstable
job build-armhf
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem ch
On Tue, 26 Oct 2021, Bertrand Marquis wrote:
> > On 26 Oct 2021, at 02:46, Stefano Stabellini wrote:
> >
> > Clarify that xen-devel is the only official communication channel.
> >
> > Signed-off-by: Stefano Stabellini
> Reviewed-by: Bertrand Marquis
Thanks Bertrand
> Just for my knowledge,
On 10/27/21 10:49 AM, Oleksandr Andrushchenko wrote:
On 27.10.21 17:46, Boris Ostrovsky wrote:
On 10/27/21 10:08 AM, Oleksandr Andrushchenko wrote:
Hi, Boris!
On 27.10.21 15:59, Boris Ostrovsky wrote:
Can you please rebase this on top of 5.15-rc7? There is a bunch of conflicts
due to cae7
Hi Oleksandr,
On 27/10/2021 09:37, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
If a PCI host bridge device is present in the device tree, but is
disabled, then its PCI host bridge driver was not instantiated.
This results in the following panic during Xen start:
(XEN) Device
flight 165899 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165899/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9a95d11023ac2f2ee49a2958cf80658270442c42
baseline version:
ovmf 2f6f3329add328103cb06
Hi Oleksandr,
On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
enough for SBDF translation to simply call VPCI_ECAM_BDF(info->gpa) as
the base address may not be aligned in the way that th
Oleksandr Andrushchenko writes ("Re: [PATCH] xen/arm: fix SBDF calculation for
vPCI MMIO handlers"):
> P.S. Sorry I failed to mark this patch as a fix for 4.16 and explain why it is
> a good candidate for 4.16 inclusion
Hello :-).
Um, can you explain what the practical impact is of not taking th
Replace the repeated pattern with a function to generate that code.
No significant functional change.
Signed-off-by: Ian Jackson
CC: Juergen Gross
---
ts-xen-build | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/ts-xen-build b/ts-xen-build
in
The existing code works in practice if the usage message always lists
the non-default, since the unlisted-in-usage options that would be
supported, but are elided, are in any case the default.
But configure might *compute* its defaults. In which case it will
list only one of them in the usage mes
The existing code depends on precisely whether the non-default option
appearing in the configure script is indeed the opposite of the option
we want to pass.
Right now it seems to be working but this seems fragile. Do it
differently.
I have verified that with current Xen, on arm64:
+ egrep -
On 27/10/2021 11:41, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 26.10.2021 18:56, Julien Grall wrote:
Hi,
On 26/10/2021 17:28, Julien Grall wrote:
On 26/10/2021 13:29, Michal Orzel wrote:
If a device is added to SMMUv1/v2 from DT and PCI
at the same time, there is a concurrent access
Roger Pau Monne writes ("[PATCH] x86/cpuid: prevent decreasing of hypervisor
max leaf on migration"):
> In order to be compatible with previous Xen versions, and not change
> max hypervisor leaf as a result of a migration, keep the clamping of
> the maximum leaf value provided to XEN_CPUID_MAX_NUM
On Wed, Oct 27, 2021 at 02:06:40PM +, Oleksandr Andrushchenko wrote:
>
>
> On 27.10.21 16:23, Roger Pau Monné wrote:
> > On Wed, Oct 27, 2021 at 11:59:47AM +, Oleksandr Andrushchenko wrote:
> >> Hi, Roger!
> >>
> >> On 27.10.21 13:17, Oleksandr Andrushchenko wrote:
> >>> Hi, Roger!
> >>>
On 10/27/21 14:01, Josef Johansson wrote:
> On 10/27/21 11:54, Josef Johansson wrote:
>> On 10/27/21 11:50, Thomas Gleixner wrote:
>>> The recent rework of PCI/MSI[X] masking moved the non-mask checks from the
>>> low level accessors into the higher level mask/unmask functions.
>>>
>>> This missed
flight 165889 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
On 27/10/2021 15:00, Roger Pau Monne wrote:
> In order to be compatible with previous Xen versions, and not change
> max hypervisor leaf as a result of a migration, keep the clamping of
> the maximum leaf value provided to XEN_CPUID_MAX_NUM_LEAVES, instead
> of doing it based on the domain type. Al
On 27.10.21 17:46, Boris Ostrovsky wrote:
>
> On 10/27/21 10:08 AM, Oleksandr Andrushchenko wrote:
>> Hi, Boris!
>>
>> On 27.10.21 15:59, Boris Ostrovsky wrote:
>>>
>>> Can you please rebase this on top of 5.15-rc7? There is a bunch of
>>> conflicts due to cae7d81a3730dfe08623f8c1083230c8d098763
On 10/27/21 10:08 AM, Oleksandr Andrushchenko wrote:
Hi, Boris!
On 27.10.21 15:59, Boris Ostrovsky wrote:
Can you please rebase this on top of 5.15-rc7? There is a bunch of conflicts
due to cae7d81a3730dfe08623f8c1083230c8d0987639.
I'll try to do that ASAP (what is the deadline for that?)
On Mon, Oct 25, 2021 at 06:42:00PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Introduce a test based on QEMU to run Xen, Dom0 and start a DomU.
> This is similar to the existing qemu-alpine-arm64.sh script and test.
> The only differences are:
> - use Debian's qemu-system-x86
Hi, Boris!
On 27.10.21 15:59, Boris Ostrovsky wrote:
>
> On 9/28/21 3:35 AM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Xen-pciback driver was designed to be built for x86 only. But it
>> can also be used by other architectures, e.g. Arm.
>>
>> Currently PCI backend imp
On 27.10.21 16:23, Roger Pau Monné wrote:
> On Wed, Oct 27, 2021 at 11:59:47AM +, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 27.10.21 13:17, Oleksandr Andrushchenko wrote:
>>> Hi, Roger!
>>>
>>> On 13.10.21 16:51, Roger Pau Monné wrote:
On Thu, Sep 30, 2021 at 10:52:15AM +0300
In order to be compatible with previous Xen versions, and not change
max hypervisor leaf as a result of a migration, keep the clamping of
the maximum leaf value provided to XEN_CPUID_MAX_NUM_LEAVES, instead
of doing it based on the domain type. Also set the default maximum
leaf without taking the d
On Mon, Oct 25, 2021 at 06:33:53PM -0700, Stefano Stabellini wrote:
> On Mon, 25 Oct 2021, Anthony PERARD wrote:
> > There is something I'm missing, how is it a problem to have a container
> > that is a bit bigger? What sort of problem could we have to deal with?
>
> It takes time to clone the con
flight 165887 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165887/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl 20 guest-localmigrate/x10 fail pass in 165875
Tests which did not succeed, but
On Wed, Oct 27, 2021 at 11:59:47AM +, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 27.10.21 13:17, Oleksandr Andrushchenko wrote:
> > Hi, Roger!
> >
> > On 13.10.21 16:51, Roger Pau Monné wrote:
> >> On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
> >>> From: Ole
On 10/26/21 5:59 AM, Jiamei Xie wrote:
-Original Message-
From: Xen-devel On Behalf Of
Juergen Gross
Sent: 2021年10月26日 15:36
To: Jiasheng Jiang ; boris.ostrov...@oracle.com;
sstabell...@kernel.org
Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v2
On 10/15/21 10:33 AM, Juergen Gross wrote:
Commit b24413180f5600 ("License cleanup: add SPDX GPL-2.0 license
identifier to files with no license") was meant to do a tree-wide
cleanup for files without any license information by adding a SPDX
GPL-2.0 line to them.
Unfortunately this was applied
On 10/14/21 3:42 PM, Stefano Stabellini wrote:
On Thu, 14 Oct 2021, Christophe JAILLET wrote:
'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.
Remove the redundant 'flush_workqueue()' calls.
This was generated with coccinelle:
On 10/12/21 10:25 AM, Juergen Gross wrote:
On 12.10.21 15:33, Thomas Gleixner wrote:
All these handlers are regular device interrupt handlers, so they already
went through the proper entry code which handles this correctly.
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: Stefano Stabel
On 10/8/21 11:01 AM, Juergen Gross wrote:
On 08.10.21 09:44, YueHaibing wrote:
Return NULL instead of passing to ERR_PTR while err is zero,
this fix smatch warnings:
drivers/xen/xen-pciback/conf_space_capability.c:163
pm_ctrl_init() warn: passing zero to 'ERR_PTR'
Fixes: a92336a1176b ("xen/
On 9/30/21 8:33 AM, Jan Beulich wrote:
The observed (by the human eye) performance difference of early boot
between native and PV-on-Xen was just too large to not look into. As
it turns out, gaining performance back wasn't all that difficult.
While the series (re)introduces a small number of P
On 9/28/21 3:35 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be used by other architectures, e.g. Arm.
Currently PCI backend implements multiple functionalities at a time,
such as:
1. It is used as
On 10/27/21 11:54, Josef Johansson wrote:
> On 10/27/21 11:50, Thomas Gleixner wrote:
>> The recent rework of PCI/MSI[X] masking moved the non-mask checks from the
>> low level accessors into the higher level mask/unmask functions.
>>
>> This missed the fact that these accessors can be invoked from
Hi, Roger!
On 27.10.21 13:17, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 13.10.21 16:51, Roger Pau Monné wrote:
>> On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> This is in preparation for dynamic assignment of the vPCI r
flight 165890 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165890/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi Julien,
On 26.10.2021 18:56, Julien Grall wrote:
> Hi,
>
> On 26/10/2021 17:28, Julien Grall wrote:
>> On 26/10/2021 13:29, Michal Orzel wrote:
>>> If a device is added to SMMUv1/v2 from DT and PCI
>>> at the same time, there is a concurrent access
>>> to a smmu master list. This could lead to
Hi, Roger!
On 13.10.21 16:51, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is in preparation for dynamic assignment of the vPCI register
>> handlers depending on the domain: hwdom or guest.
>> The nee
1 - 100 of 121 matches
Mail list logo
