flight 169323 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169323/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Wed, Apr 06, 2022 at 08:25:32PM -0400, Konrad Rzeszutek Wilk wrote:
> > diff --git a/arch/powerpc/platforms/pseries/svm.c
> > b/arch/powerpc/platforms/pseries/svm.c
> > index c5228f4969eb2..3b4045d508ec8 100644
> > --- a/arch/powerpc/platforms/pseries/svm.c
> > +++ b/arch/powerpc/platforms/pser
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
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
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.
Acked-by: Helge Deller # parisc
Signed-off-by: Dmitr
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.
Acked-by: Juergen Gross
Signed-off-by: Dmitry Osipen
On 04/06, Christoph Hellwig wrote:
> Secure erase is a very different operation from discard in that it is
> a data integrity operation vs hint. Fully split the limits and helper
> infrastructure to make the separation more clear.
>
> Signed-off-by: Christoph Hellwig
> ---
> block/blk-core.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 power-off API.
Acked-by: Guo Ren
Signed-off-by: Dmitry Osipenko
--
Add sanity check which ensures that there are no two restart handlers
registered using the same priority. This requirement will become mandatory
once all drivers will be converted to the new API and such errors will be
fixed.
Signed-off-by: Dmitry Osipenko
---
kernel/reboot.c | 15 ++
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 | 38 ++
1 file changed, 14 insertion
All pm_power_off_prepare() users were converted to sys-off handler API.
Remove the obsolete callback.
Signed-off-by: Dmitry Osipenko
---
include/linux/pm.h | 1 -
kernel/reboot.c| 11 ---
2 files changed, 12 deletions(-)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index ff
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
Switch to sys-off 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 c992e57b2c79..426297258e26
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 edf3ba74
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/
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
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.
Acked-by: Michael Ellerman
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 power-off API.
Acked-by: Catalin Marinas
Signed-off-by: Dmitry Osip
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.
Acked-by: Palmer Dabbelt
Signed-off-by: Dmitry Osipe
SoC platforms often have multiple ways 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 fu
Add variant of atomic/blocking_notifier_chain_register() functions that
doesn't allow to register notifier using a duplicated priority. The -EBUSY
error code is returned in this case by the new API functions.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 5 +++
kernel/notifier.c
Add blocking_notifier_call_chain_is_empty() that returns true if call
chain is empty.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 2 ++
kernel/notifier.c| 13 +
2 files changed, 15 insertions(+)
diff --git a/include/linux/notifier.h b/include/linux/notifie
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.
Reviewed-by: Russell King (Oracle)
Signed-off-by: Dm
flight 169321 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169321/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169319 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169319/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169317 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169317/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169316 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169315 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169315/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169314 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169314/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169309 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169309/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169292
Tests which did not succeed
flight 169313 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169313/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169312 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169312/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi,
On 09/04/2022 02:00, Stefano Stabellini wrote:
On Wed, 23 Mar 2022, Rahul Singh wrote:
in dom0less system. This patch introduce the new feature to support the
signaling between two domUs in dom0less system.
Signed-off-by: Rahul Singh
---
docs/designs/dom0less-evtchn.md | 96
Hi Rahul,
Title: s/../.../
On 23/03/2022 15:43, Rahul Singh wrote:
in dom0less system. This patch introduce the new feature to support the
s/introduce/introduces/
s/the new/a/
signaling between two domUs in dom0less system.
Did you intend to add a newline before the second sentence?
Sig
On Sat, Apr 09, 2022 at 06:50:41AM +0200, Christoph Hellwig wrote:
> Abstract away implementation details from file systems by providing a
> block_device based helper to retrieve the discard granularity.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Martin K. Petersen
> Acked-by: Christoph
On Sat, Apr 09, 2022 at 06:50:40AM +0200, Christoph Hellwig wrote:
> Just use a non-zero max_discard_sectors as an indicator for discard
> support, similar to what is done for write zeroes.
>
> The only places where needs special attention is the RAID5 driver,
> which must clear discard support fo
On Sat, Apr 09, 2022 at 06:50:24AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Johannes Thumshirn
Acked-by: David Sterba
flight 169311 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169311/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
> From: Anthony PERARD
> Sent: Tuesday, March 22, 2022 11:22 AM
> To: xen-devel@lists.xenproject.org
> Cc: Anthony Perard ; Jan Beulich
> ; Daniel P . Smith ; Julien
> Grall ; Andrew Cooper ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini ; Wei Liu ; Roger Pau Monne
> ; Konrad Rzeszut
Hi Ross,
Could you also ack this livpatch change?
Thanks.
On Tue, Mar 22, 2022 at 11:22:38AM +, Anthony PERARD wrote:
> This implement out-of-tree support, there's two ways to create an
> out-of-tree build tree (after that, `make` in that new directory
> works):
> make O=build
> mkdi
Hello David,
Thanks for reviewing the design and sorry for the late reply.
> On 24 Mar 2022, at 12:24 pm, David Vrabel wrote:
>
>
>
> On 23/03/2022 15:43, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less
On 11.04.2022 17:20, 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 different cpu pools
flight 169310 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169310/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi Stefano,
Thanks for reviewing the design.
> On 9 Apr 2022, at 2:00 am, Stefano Stabellini wrote:
>
> On Wed, 23 Mar 2022, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>>
>> Signed-off-by: Rah
Currently cpupool0 can use only the default scheduler, and
cpupool_create has an hardcoded behavior when creating the pool 0
that doesn't allocate new memory for the scheduler, but uses the
default scheduler structure in memory.
With this commit it is possible to allocate a different scheduler for
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 different cpu pools for each node.
The feature on arm relies on a spe
Add a static function to retrieve the scheduler pointer using the
scheduler name.
Add a public function to retrieve the scheduler id by the scheduler
name that makes use of the new static function.
Take the occasion to replace open coded scheduler search with the
new static function in scheduler_
With the introduction of boot time cpupools, Xen can create many
different cpupools at boot time other than cpupool with id 0.
Since these newly created cpupools can't have an
entry in Xenstore, create the entry using xen-init-dom0
helper with the usual convention: Pool-.
Given the change, remove
Introduce domain-cpupool property of a xen,domain device tree node,
that specifies the cpupool device tree handle of a xen,cpupool node
that identifies a cpupool created at boot time where the guest will
be assigned on creation.
Add member to the xen_domctl_createdomain public interface so the
XEN
Cpu0 must remain in cpupool0, otherwise some operations like moving cpus
between cpupools, cpu hotplug, destroying cpupools, shutdown of the host,
might not work in a sane way.
Signed-off-by: Luca Fancellu
---
Changes in v7:
- new patch
---
xen/common/sched/cpupool.c | 8 +++-
1 file changed
Create new public function to create cpupools, can take as parameter
the scheduler id or a negative value that means the default Xen
scheduler will be used.
Signed-off-by: Luca Fancellu
Reviewed-by: Juergen Gross
---
Changes in v7:
- no changes
Changes in v6:
- add R-by
Changes in v5:
- no chang
This serie introduces a feature for Xen to create cpu pools at boot time, the
feature is enabled using a configurable that is disabled by default.
The boot time cpupool feature relies on the device tree to describe the cpu
pools.
Another feature is introduced by the serie, the possibility to assign
Hello all,
EXECUTIVE SUMMARY
The current form of the Xen Summit this year we’re considering is as follows:
1. Two days of “primarily virtual” talks, with a physical add-on for those in
the Cambridge UK area, or willing to fly there. This would be relatively
low-key, probably hosted on a compa
On Fri, 2022-04-08 at 11:20 +, Dario Faggioli wrote:
> On Thu, 2022-04-07 at 15:27 +0200, Jan Beulich wrote:
> >
> > Credit2 moving the vCPU-s off of their initially assigned ones
> > right
> > away of course renders sched_select_initial_cpu()'s use of
> > cpu_cycle()
> > pretty useless.
> >
flight 169308 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Sat, Apr 09, 2022 at 06:50:40AM +0200, Christoph Hellwig wrote:
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index efb85c6d8e2d5..7e07dd69262a7 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1607,10 +1607,8 @@ static void nvme_config_discar
flight 169304 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169304/
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 169307 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169306 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 09/04/2022 06:50, Christoph Hellwig wrote:
> Just use a non-zero max_discard_sectors as an indicator for discard
> support, similar to what is done for write zeroes.
>
> The only places where needs special attention is the RAID5 driver,
> which must clear discard support for security reasons by
On 11.04.2022 13:00, Julien Grall wrote:
> On 11/04/2022 11:45, Jan Beulich wrote:
>> On 11.04.2022 12:25, Julien Grall wrote:
>>> On 11/04/2022 07:13, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1559,6 +1559,16 @@ void evtchn_
Hi Luca,
On 11/04/2022 12:30, Luca Fancellu wrote:
On 11 Apr 2022, at 11:58, Julien Grall wrote:
Hi Luca,
On 08/04/2022 09:45, Luca Fancellu wrote:
diff --git a/docs/misc/arm/device-tree/cpupools.txt
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..40cc8135c
flight 169305 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169305/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169294 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169294/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169286
test-armhf-armhf-libvirt 16 saver
> On 11 Apr 2022, at 11:58, Julien Grall wrote:
>
> Hi Luca,
>
> On 08/04/2022 09:45, Luca Fancellu wrote:
>> diff --git a/docs/misc/arm/device-tree/cpupools.txt
>> b/docs/misc/arm/device-tree/cpupools.txt
>> new file mode 100644
>> index ..40cc8135c66f
>> --- /dev/null
>> +++ b/d
Hi Julien,
On 11.04.2022 12:23, Julien Grall wrote:
> Hi,
>
> On 11/04/2022 07:24, Michal Orzel wrote:
>> On 08.04.2022 16:09, Peng Fan (OSS) wrote:
>>> From: Peng Fan
>>>
>>> Signed-off-by: Peng Fan
>>> ---
>>> xen/arch/arm/Kconfig.debug | 14 +++
>>> xen/arch/arm/arm64/deb
https://doodle.com/meeting/participate/id/b822G1ge
I will probably leave the Doodle opened for few days (like up to Monday
evening) until we can decide the best schedule without waiting too long. When
I'll have the validated time slot, I'll communicate about it here.
So, as planned, here is
Hi Julien,
On 11.04.2022 12:20, Julien Grall wrote:
> Hi,
>
> On 11/04/2022 07:26, Michal Orzel wrote:
>> On 08.04.2022 16:09, Peng Fan (OSS) wrote:
>>> From: Peng Fan
>>>
>>> The i.MX LPUART Documentation:
>>> https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
>>> Chatper 13.6 Low Power Univ
Hi,
On 11/04/2022 11:45, Jan Beulich wrote:
On 11.04.2022 12:25, Julien Grall wrote:
On 11/04/2022 07:13, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
unsigned int port;
stru
Hi,
On 08/04/2022 16:26, Roger Pau Monné wrote:
On Fri, Apr 08, 2022 at 12:24:27PM +0100, Julien Grall wrote:
Hi Roger,
On 08/04/2022 12:16, Roger Pau Monné wrote:
On Fri, Apr 08, 2022 at 12:08:02PM +0100, Julien Grall wrote:
Hi,
On 08/04/2022 12:01, Roger Pau Monné wrote:
I could add a su
Hi Luca,
On 08/04/2022 09:45, Luca Fancellu wrote:
diff --git a/docs/misc/arm/device-tree/cpupools.txt
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..40cc8135c66f
--- /dev/null
+++ b/docs/misc/arm/device-tree/cpupools.txt
@@ -0,0 +1,140 @@
+Boot time cpupools
flight 169302 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169302/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 11.04.2022 12:25, Julien Grall wrote:
> On 11/04/2022 07:13, Jan Beulich wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
>> unsigned int port;
>> struct evtchn *chn
Hi Stefano,
> On 9 Apr 2022, at 02:44, Stefano Stabellini wrote:
>
> On Fri, 8 Apr 2022, Stefano Stabellini wrote:
>> On Wed, 23 Mar 2022, Rahul Singh wrote:
>>> in dom0less system. This patch introduce the new feature to support the
>>> signaling between two domUs in dom0less system.
>>>
>>> S
On 11.04.2022 12:29, Roger Pau Monné wrote:
> On Mon, Apr 11, 2022 at 11:47:46AM +0200, Jan Beulich wrote:
>> While it is okay for IOMMU page tables to be set up for guests starting
>> in PoD mode, actual device assignment may only occur once all PoD
>> entries have been removed from the P2M. So fa
Hi Michal,
On 11/04/2022 08:02, Michal Orzel wrote:
This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defin
flight 169296 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169296/
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-arm64-libvirt
Hi Jan,
> -Original Message-
> From: Jan Beulich
> > Since you also mentioned the changelog entry, I will take a note of this
> > series and we can have a discussion about adding it when we do the
> > next Xen release (4.17). Would that sound ok with you?
>
> "Adding it" where? Maybe you
On Mon, Apr 11, 2022 at 11:47:46AM +0200, Jan Beulich wrote:
> While it is okay for IOMMU page tables to be set up for guests starting
> in PoD mode, actual device assignment may only occur once all PoD
> entries have been removed from the P2M. So far this was enforced only
> for boot-time assignme
On Mon, 2022-04-11 at 08:29 +, Luca Fancellu wrote:
> > On 11 Apr 2022, at 07:15, Jan Beulich wrote:
> > On 08.04.2022 22:25, Stefano Stabellini wrote:
> > > In my opinion it is best if the maintenance of boot_cpupools.c
> > > falls
> > > under "CPU POOLS". Luca, you can retain my reviewed-by
Hi,
On 11/04/2022 07:13, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
unsigned int port;
struct evtchn *chn;
+/*
+ * The work done below is an attempt to keep pIRQ-
Hi,
On 11/04/2022 07:24, Michal Orzel wrote:
On 08.04.2022 16:09, Peng Fan (OSS) wrote:
From: Peng Fan
Signed-off-by: Peng Fan
---
xen/arch/arm/Kconfig.debug | 14 +++
xen/arch/arm/arm64/debug-imx-lpuart.inc | 52 +
2 files changed, 66 insertions(
On 11.04.2022 12:20, Luca Fancellu wrote:
>
>
>> On 11 Apr 2022, at 10:08, Jan Beulich wrote:
>>
>> On 11.04.2022 10:54, Luca Fancellu wrote:
On 8 Apr 2022, at 13:10, Jan Beulich wrote:
On 08.04.2022 13:15, Luca Fancellu wrote:
>> On 8 Apr 2022, at 11:24, Jan Beulich wrote:
>
Hi,
On 11/04/2022 07:26, Michal Orzel wrote:
On 08.04.2022 16:09, Peng Fan (OSS) wrote:
From: Peng Fan
The i.MX LPUART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
Chatper 13.6 Low Power Universal Asynchronous Receiver/
Transmitter (LPUART)
Tested-by: Henry Wang
Sign
> On 11 Apr 2022, at 10:08, Jan Beulich wrote:
>
> On 11.04.2022 10:54, Luca Fancellu wrote:
>>> On 8 Apr 2022, at 13:10, Jan Beulich wrote:
>>> On 08.04.2022 13:15, Luca Fancellu wrote:
> On 8 Apr 2022, at 11:24, Jan Beulich wrote:
> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>
On 11.04.2022 12:01, Andrew Cooper wrote:
> On 11/04/2022 10:35, Jan Beulich wrote:
>> Prior extension of these functions to enable per-device quarantine page
>> tables already didn't add more locking there, but merely left in place
>> what had been there before. But really locking is unnecessary h
Hi Michal,
On 11/04/2022 08:03, Michal Orzel wrote:
Populate header file xen.lds.h with the first portion of macros storing
constructs common to x86 and arm linker scripts. Replace the original
constructs with these helpers.
No functional improvements to x86 linker script.
Making use of common
Hi Michal,
On 11/04/2022 08:02, Michal Orzel wrote:
Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen.lds.h to store the internals mutual to all
the linker scripts.
Include this hea
On 11.04.2022 12:11, Henry Wang wrote:
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
>>>
>>> May I ask for an ack or otherwise for the changelog entry, please?
>>
>> Ping? This is the only thing missing for me to commit the remaining
>> parts of this series.
>
> Sorry for
flight 169292 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169292/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 169273
Tests which are fa
Hi Jan,
> >>> Signed-off-by: Jan Beulich
> >>
> >> Acked-by: Roger Pau Monné
> >
> > May I ask for an ack or otherwise for the changelog entry, please?
>
> Ping? This is the only thing missing for me to commit the remaining
> parts of this series.
Sorry for the late response, the previous e-ma
On 11/04/2022 10:35, Jan Beulich wrote:
> Prior extension of these functions to enable per-device quarantine page
> tables already didn't add more locking there, but merely left in place
> what had been there before. But really locking is unnecessary here:
> We're running with pcidevs_lock held (i.
flight 169300 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169300/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 06.04.2022 16:23, Jan Beulich wrote:
> On 05.04.2022 10:45, Roger Pau Monné wrote:
>> On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote:
>>> GrUB2 can be told to leave the screen in the graphics mode it has been
>>> using (or any other one), via "set gfxpayload=keep" (or suitable
>>> v
While it is okay for IOMMU page tables to be set up for guests starting
in PoD mode, actual device assignment may only occur once all PoD
entries have been removed from the P2M. So far this was enforced only
for boot-time assignment, and only in the tool stack.
Also use the new function to replace
To handle phantom devices, several functions are passed separate "devfn"
arguments besides a PCI device. In such cases we want to log the phantom
device's coordinates instead of the main one's. (Note that not all of
the instances being changed are fallout from the referenced commit.)
Fixes: 1ee144
At their use sites the numeric suffixes are at least odd to read, first
and foremost for PCI_DEVFN2() where the suffix doesn't even match the
number of arguments. Make use of count_args() such that a single flavor
each suffices (leaving aside helper macros, which aren't supposed to be
used from the
There's no good reason to use these when we already have a pci_sbdf_t
type object available. This extends to the use of PCI_BUS() in
pci_ecam_map_bus() as well.
No change to generated code (with gcc11 at least, and I have to admit
that I didn't expect compilers to necessarily be able to spot the
o
struct pci_dev has the wanted value directly available; use it. Note
that this fixes a - imo benign - mistake in reassign_device(): The unity
map removal ought to be based on the passed in devfn (as is the case on
the establishing side). This is benign because the mappings would be
removed anyway a
1 - 100 of 115 matches
Mail list logo
