Hi Dmitry,
On Tue, Apr 12, 2022 at 1:38 AM Dmitry Osipenko
wrote:
> 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.
> Changelog:
>
> v7: - Rebased
flight 169320 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169320/
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 169324 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169324/
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 169325 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169325/
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 Mon, Apr 11, 2022 at 11:36:23AM +0200, Jan Beulich wrote:
> It's not only misplaced, but entirely unused.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On Mon, Apr 11, 2022 at 11:36:43AM +0200, Jan Beulich wrote:
> While 97af062b89d5 ("IOMMU/x86: maintain a per-device pseudo domain ID")
> took care of not making things worse, plugging pre-existing leaks wasn't
> the purpose of that change; they're not security relevant after all.
>
> Signed-off-b
flight 169326 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169326/
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 169322 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169322/
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
flight 169318 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169318/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail pass in 169309
Tests which did not succeed, but
On Mon, Apr 11, 2022 at 11:37:28AM +0200, Jan Beulich wrote:
> The field taking the value 7 (resulting in 18-bit DIDs when using the
> calculation in cap_ndoms(), when the DID fields are only 16 bits wide)
> is reserved. Instead of misbehaving in case we would encounter such an
> IOMMU, refuse to u
flight 169327 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169327/
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 Mon, Apr 11, 2022 at 11:37:52AM +0200, Jan Beulich wrote:
> 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
>> ---
>> MAINTAINERS | 2 +-
>> docs/misc/arm/device-tree/cpupools.txt | 140 +
>> xen/arch/arm/domain_build.c | 5 +-
>> xen/arch/arm/include/asm/smp.h | 3 +
>> xen/common/Kconfig | 7 +
>
> For consistency, should the addition here - with ...
>
>> xen/common/sched/Makefile | 1 +
>
On 4/12/22 10:06, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Tue, Apr 12, 2022 at 1:38 AM Dmitry Osipenko
> wrote:
>> Problem
>> ---
>>
>> SoC devices require power-off call chaining functionality from kernel.
>> We have a widely used restart chaining provided by restart notifier API,
>> b
On 4/12/22 02:38, 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.
>
On 4/12/22 02:38, Dmitry Osipenko wrote:
> 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
On Mon, Apr 11, 2022 at 11:38:28AM +0200, Jan Beulich wrote:
> 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
On Mon, Apr 11, 2022 at 11:40:24AM +0200, Jan Beulich wrote:
> 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 ad
On 12.04.2022 11:50, Luca Fancellu wrote:
>
>>> ---
>>> MAINTAINERS | 2 +-
>>> docs/misc/arm/device-tree/cpupools.txt | 140 +
>>> xen/arch/arm/domain_build.c | 5 +-
>>> xen/arch/arm/include/asm/smp.h | 3 +
>>> xen/common/Kconfig | 7 +
>>
>> For consistency, should the addition here
While not immediately useful - a new binutils release would first need
cutting - I thought I'd post early the patches utilizing new functionality
there. The changes made are largely benign with gas 2.38 or older.
1: improve .debug_line contents for assembly sources
2: annotate entry points with ty
While future gas versions will allow line number information to be
generated for all instances of .irp and alike [1][2], the same isn't
true (nor immediately intended) for .macro [3]. Hence macros, when they
do more than just invoke another macro or issue an individual insn, want
to have .line dire
Future gas versions will generate minimalistic Dwarf debug info for
items annotated as functions and having their sizes specified [1].
"Borrow" Arm's END() and ENDPROC() to avoid open-coding (and perhaps
typo-ing) the respective directives.
Signed-off-by: Jan Beulich
[1]
https://sourceware.org/
On 12.04.2022 11:22, Roger Pau Monné wrote:
> On Mon, Apr 11, 2022 at 11:37:28AM +0200, Jan Beulich wrote:
>> The field taking the value 7 (resulting in 18-bit DIDs when using the
>> calculation in cap_ndoms(), when the DID fields are only 16 bits wide)
>> is reserved. Instead of misbehaving in cas
On 12.04.2022 12:05, Roger Pau Monné wrote:
> On Mon, Apr 11, 2022 at 11:38:28AM +0200, Jan Beulich wrote:
>> 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 m
On Mon, Apr 11, 2022 at 11:42:05AM +0200, Jan Beulich wrote:
> 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 (l
flight 169329 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169329/
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 Mon, Apr 11, 2022 at 11:35:54AM +0200, 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
Or else all interrupts will get bound to (v)CPU 0.
This doesn't cause issues on small boxes, but boxes with a non-trivial
amount of CPUs can struggle without interrupts being balanced across
available vCPUs, as the number of vCPUs offered to dom0 matches the
number of physical CPUs.
For example s
On 12.04.2022 13:05, Roger Pau Monné wrote:
> On Mon, Apr 11, 2022 at 11:35:54AM +0200, 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 l
flight 169331 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169331/
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 Tue, Apr 12, 2022 at 02:17:16PM +0200, Jan Beulich wrote:
> On 12.04.2022 13:05, Roger Pau Monné wrote:
> > On Mon, Apr 11, 2022 at 11:35:54AM +0200, Jan Beulich wrote:
> >> Prior extension of these functions to enable per-device quarantine page
> >> tables already didn't add more locking there,
Hi James,
On Tue, Mar 01, 2022 at 09:35:13AM +, James Dingwall wrote:
> The set_mtu() function of xen-network-common.sh currently has this code:
>
> if [ ${type_if} = vif ]
> then
> local dev_=${dev#vif}
> local domid=${dev_%.*}
> local devi
On 12.04.2022 14:54, Roger Pau Monné wrote:
> On Tue, Apr 12, 2022 at 02:17:16PM +0200, Jan Beulich wrote:
>> On 12.04.2022 13:05, Roger Pau Monné wrote:
>>> On Mon, Apr 11, 2022 at 11:35:54AM +0200, Jan Beulich wrote:
Prior extension of these functions to enable per-device quarantine page
>>>
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
Roger Pau Monne writes ("[PATCH] osstest: install irqbalance"):
> Or else all interrupts will get bound to (v)CPU 0.
>
> This doesn't cause issues on small boxes, but boxes with a non-trivial
> amount of CPUs can struggle without interrupts being balanced across
> available vCPUs, as the number of
flight 169334 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169334/
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 Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
> On 08.04.2022 13: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
On Tue, 2022-04-12 at 15:48 +, Dario Faggioli wrote:
> On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
>
>
> And while doing that, I think we should consolidate touching the
> affinity only there, avoiding altering it twice. After all, we
> already
> know how it should look like, so let
On Tue, 2022-04-12 at 16:11 +, Dario Faggioli wrote:
> On Tue, 2022-04-12 at 15:48 +, Dario Faggioli wrote:
> > On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
> >
> >
> > And while doing that, I think we should consolidate touching the
> > affinity only there, avoiding altering it
On Tue, 2022-04-12 at 16:11 +, Dario Faggioli wrote:
> + else if ( is_hardware_domain(d) )
> + {
> + /*
> + * In absence of dom0_vcpus_pin, the hard and soft affinity
> of
> + * domain-0 is controlled by the dom0_nodes parameter. At
> this point
> + * it has
flight 169335 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169335/
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 169328 xen-unstable real [real]
flight 169337 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169328/
http://logs.test-lab.xenproject.org/osstest/logs/169337/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 169330 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169330/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169241
test-amd64-amd64-xl-qemut-win7-a
flight 169338 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169338/
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 Mon, 11 Apr 2022, Julien Grall wrote:
> 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
flight 169339 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169339/
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 169333 xen-4.16-testing real [real]
flight 169340 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169333/
http://logs.test-lab.xenproject.org/osstest/logs/169340/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 169341 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169341/
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 Tue, 12 Apr 2022, Jan Beulich wrote:
> On 12.04.2022 11:50, Luca Fancellu wrote:
> >>> ---
> >>> MAINTAINERS | 2 +-
> >>> docs/misc/arm/device-tree/cpupools.txt | 140 +
> >>> xen/arch/arm/domain_build.c | 5 +-
> >>> xen/arch/arm/include/asm/smp.h | 3 +
> >>> xen/common/Kconfig |
flight 169342 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169342/
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 169343 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169343/
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 169344 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169344/
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, 6 Apr 2022, Julien Grall wrote:
> But if we use the 'connection status' field, then you could just delay the
> initialization until you receive an event and the connection status is
> connected.
I prototyped this approach and I managed to validate it successfully.
See attached patches for
flight 169345 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169345/
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 169349 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169349/
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 169350 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169350/
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 Mon, Apr 04, 2022 at 07:05:44AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series tries to clean up the swiotlb initialization, including
> that of swiotlb-xen. To get there is also removes the x86 iommu table
> infrastructure that massively obsfucates the initialization path.
>
> Git
57 matches
Mail list logo
