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
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
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 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
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 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
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 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
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 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
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
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 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
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 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 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
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
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 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 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
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
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
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
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
>>>
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 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,
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 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
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 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
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: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
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 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
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/
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
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
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
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 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 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 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 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
>> ---
>> 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 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
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: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 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
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 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
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
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.
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
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 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
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
57 matches
Mail list logo
