flight 169147 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169147/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-livepatch 13 livepatch-runfail REGR. vs. 168506
test-amd64-i38
Hi Christoph,
On Mon, Apr 04, 2022 at 05:05:56AM +, Christoph Hellwig wrote:
> From: Christoph Hellwig
> Subject: [PATCH 12/15] swiotlb: provide swiotlb_init variants that remap
> the buffer
>
> To shared more code between swiotlb and xen-swiotlb, offer a
> swiotlb_init_remap interface and
flight 169145 linux-linus real [real]
flight 169155 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169145/
http://logs.test-lab.xenproject.org/osstest/logs/169155/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
flight 169153 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169153/
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
Let the caller chose a zone to allocate from. This will be used
later on by the xen-swiotlb initialization on arm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
arch/x86/pci/sta2x11-fixup.c | 2 +-
include/linux/swiotlb.h | 2 +-
kernel/dma/swiotlb.c | 7 ++--
Pass a bool to pass if swiotlb needs to be enabled based on the
addressing needs and replace the verbose argument with a set of
flags, including one to force enable bounce buffering.
Note that this patch removes the possibility to force xen-swiotlb
use using swiotlb=force on the command line on x8
To shared more code between swiotlb and xen-swiotlb, offer a
swiotlb_init_remap interface and add a remap callback to
swiotlb_init_late that will allow Xen to remap the buffer the
buffer without duplicating much of the logic.
Signed-off-by: Christoph Hellwig
---
arch/x86/pci/sta2x11-fixup.c | 2
Reuse the generic swiotlb initialization for xen-swiotlb. For ARM/ARM64
this works trivially, while for x86 xen_swiotlb_fixup needs to be passed
as the remap argument to swiotlb_init_remap/swiotlb_init_late.
Note that the lower bound of the swiotlb size is changed to the smaller
IO_TLB_MIN_SLABS
No users left.
Signed-off-by: Christoph Hellwig
---
include/linux/swiotlb.h | 2 --
kernel/dma/swiotlb.c| 77 +++--
2 files changed, 20 insertions(+), 59 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 7b50c82f84ce9..7ed
gets pulled in by all drivers using the DMA API.
Remove x86 internal variables and unnecessary includes from it.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/dma-mapping.h | 11 ---
arch/x86/include/asm/iommu.h | 2 ++
2 files changed, 2 insertions(+), 11 deletions(-
Move enabling SWIOTLB_FORCE for guest memory encryption into common code.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/cpu/mshyperv.c | 8
arch/x86/kernel/pci-dma.c | 8
arch/x86/mm/mem_encrypt_amd.c | 3 ---
3 files changed, 8 insertions(+), 11 deletions(-)
diff
Power SVM wants to allocate a swiotlb buffer that is not restricted to
low memory for the trusted hypervisor scheme. Consolidate the support
for this into the swiotlb_init interface by adding a new flag.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/svm.h | 4
arch/p
From: Stefano Stabellini
It used to be that Linux enabled swiotlb-xen when running a dom0 on ARM.
Since f5079a9a2a31 "xen/arm: introduce XENFEAT_direct_mapped and
XENFEAT_not_direct_mapped", Linux detects whether to enable or disable
swiotlb-xen based on the new feature flags: XENFEAT_direct_mapp
If force bouncing is enabled we can't release the buffers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
kernel/dma/swiotlb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 73a41cec9e386..98bb0eb44a7bf 100644
--- a/
The IOMMU table tries to separate the different IOMMUs into different
backends, but actually requires various cross calls.
Rewrite the code to do the generic swiotlb/swiotlb-xen setup directly
in pci-dma.c and then just call into the IOMMU drivers.
Signed-off-by: Christoph Hellwig
---
arch/ia64
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 tree:
git://git.infradead.org/users/hch/misc.git swiotlb-init-cleanup
Gitw
Use the more specific is_swiotlb_active check instead of checking the
global swiotlb_force variable.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
kernel/dma/direct.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/direct.h b/kernel/dma/direc
Use the generic swiotlb initialization helper instead of open coding it.
Signed-off-by: Christoph Hellwig
Acked-by: Thomas Bogendoerfer
---
arch/mips/cavium-octeon/dma-octeon.c | 15 ++-
arch/mips/pci/pci-octeon.c | 2 +-
2 files changed, 3 insertions(+), 14 deletions(-)
swiotlb_late_init_with_default_size is an overly verbose name that
doesn't even catch what the function is doing, given that the size is
not just a default but the actual requested size.
Rename it to swiotlb_init_late.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
arch/x8
Remove the bogus Xen override that was usually larger than the actual
size and just calculate the value on demand. Note that
swiotlb_max_segment still doesn't make sense as an interface and should
eventually be removed.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
driver
flight 169150 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169150/
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 169143 xen-4.15-testing real [real]
flight 169149 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169143/
http://logs.test-lab.xenproject.org/osstest/logs/169149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 169148 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169148/
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
I'm working on resolving a bug in Qubes OS. The problem is that
when someone gives a VM too much RAM the GPU passthrough doesn't
work as intended. I think it's because in these cases RAM overlaps
with PCI addresses and memory relocation doesn'
flight 169144 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169144/
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 169140 xen-4.14-testing real [real]
flight 169146 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169140/
http://logs.test-lab.xenproject.org/osstest/logs/169146/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 169138 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169138/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169127
test-amd64-amd64-qemuu-nested-amd 2
flight 169141 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169141/
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 169137 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169137/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail in 169125 pass
in 169137
test-armhf-armhf-xl-rt
flight 169139 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169139/
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
flight 169134 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169134/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169100
test-armhf-armhf-libvirt 16 saver
flight 169132 xen-4.15-testing real [real]
flight 169142 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169132/
http://logs.test-lab.xenproject.org/osstest/logs/169142/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 169135 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169135/
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
33 matches
Mail list logo
