flight 162659 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162659/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
flight 162674 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162674/
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 162650 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
flight 162665 xen-unstable-smoke real [real]
flight 162671 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162665/
http://logs.test-lab.xenproject.org/osstest/logs/162671/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
flight 162643 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162643/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Fri, 11 Jun 2021, Jan Beulich wrote:
> The Arm ARM's description of MSR (ARM DDI 0406C.d section B9.3.12)
> doesn't even allow for plain "SPSR" here, and while gas accepts this, it
> takes it to mean SPSR_cf. Yet surely all of SPSR wants updating on this
> path, not just the lowest and highest 8
flight 162656 xen-unstable-smoke real [real]
flight 162663 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162656/
http://logs.test-lab.xenproject.org/osstest/logs/162663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
flight 162633 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162633/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 162533
test-xtf-amd64-amd
flight 162637 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162637/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
On 6/2/21 12:53 AM, Christoph Hellwig wrote:
> Hi all,
>
> this series is the scond part of cleaning up lifetimes and allocation of
> the gendisk and request_queue structure. It adds a new interface to
> allocate the disk and queue together for blk based drivers, and uses that
> in all drivers th
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-examine
testid reboot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qe
flight 162647 xen-unstable-smoke real [real]
flight 162652 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162647/
http://logs.test-lab.xenproject.org/osstest/logs/162652/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
CC: George Dunlap
Suggested-by: Jan Beulich
Signed-off-by: Ian Jackson
---
ts-xen-build | 4
1 file changed, 4 insertions(+)
diff --git a/ts-xen-build b/ts-xen-build
index deec52b2..af0dd894 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -132,6 +132,10 @@ END
# on Xen. Fo
See the comment at the top of test-tsx.c for details.
This covers various complexities encountered while trying to address the
recent TSX deprecation on client parts.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
tools/tests/Makefile | 1 +
tool
... so tests can peek at the internals, without the structure being generally
available to users of the library.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
tools/libs/guest/xg_cpuid_x86.c | 11 +--
tools/libs/guest/xg_private.h | 9
The logic to disallow writes to the TSC is out-of-place, and should be in
check_resource_access() rather than in resource_access().
Split the existing allow_access_msr() into two - msr_{read,write}_allowed() -
and move all permissions checks here.
Furthermore, guard access to MSR_IA32_CMT_{EVTSEL
We are going to want this to write some tests with.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/platform_hypercall.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/platform_hypercall.c
b/xen/arch/x86/platform_hyper
See patch 5 for details.
Andrew Cooper (5):
x86/platform: Improve MSR permission handling for XENPF_resource_op
x86/platform: Permit reading the TSX control MSRs via XENPF_resource_op
x86/msr: Expose MSR_ARCH_CAPS in the raw and host policies
libs/guest: Move struct xc_cpu_policy into xg_p
MSR_ARCH_CAPS is still not supported for guests (other than the hardware
domain) yet, until the toolstack learns how to construct an MSR policy.
However, we want access to the host ARCH_CAPS_TSX_CTRL value in particular for
testing purposes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC:
I don't have the HW to verify the change. Hopefully I use the right
device struct for is_swiotlb_active.
v9 here: https://lore.kernel.org/patchwork/cover/1445081/
On Mon, Jun 7, 2021 at 11:28 AM Claire Chang wrote:
>
> On Sat, Jun 5, 2021 at 1:48 AM Will Deacon wrote:
> >
> > Hi Claire,
> >
> > On Thu, May 27, 2021 at 08:58:30PM +0800, Claire Chang wrote:
> > > This series implements mitigations fo
I'm not sure if this would break arch/x86/pci/sta2x11-fixup.c
swiotlb_late_init_with_default_size is called here
https://elixir.bootlin.com/linux/v5.13-rc5/source/arch/x86/pci/sta2x11-fixup.c#L60
On Fri, Jun 11, 2021 at 11:27 PM Claire Chang wrote:
>
> Always have the pointer to the swiotlb pool
Add a new function, release_slots, to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kern
Add a new wrapper __dma_direct_free_pages() that will be useful later
for swiotlb_free().
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 078f7087e466..eb409832
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 15 +++
kernel/dma/swiotlb.c| 35 +--
2 files changed, 48 insertions(+), 2 deletions(-)
di
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6 +
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock
Move the maintenance of alloc_size to find_slots for better code
reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index e5ccc198d0a7..364c6c822063 100
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7 ---
kernel/dma/direct.c
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 3 +-
kernel/dma/Kconfig | 14
kernel/dma/swiotlb.c| 75 +
3 files changed, 91
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
---
drivers/of/device.c | 3 +++
include/linux/device.h | 4
include/linux/swiotlb.h | 8
kernel/dma/swiotlb.c| 8
4 f
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/ke
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 53 ++--
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/kernel/dma/swio
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
On 6/11/21 5:55 AM, Roman Skakun wrote:
>
> +static int
> +xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + unsigned long user_count = vma_pages(vma);
> +
flight 162623 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162623/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
On Fri, 11 Jun 2021, 15:02 Jan Beulich, wrote:
> On 11.06.2021 12:41, Julien Grall wrote:
> > On Fri, 11 Jun 2021, 11:16 Jan Beulich, wrote:
> >
> >> On 11.06.2021 10:00, Julien Grall wrote:
> >>> On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote:
> >>>
> The Arm ARM's description of MSR doesn
flight 162642 xen-unstable-smoke real [real]
flight 162646 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162642/
http://logs.test-lab.xenproject.org/osstest/logs/162646/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
The Arm ARM's description of MSR (ARM DDI 0406C.d section B9.3.12)
doesn't even allow for plain "SPSR" here, and while gas accepts this, it
takes it to mean SPSR_cf. Yet surely all of SPSR wants updating on this
path, not just the lowest and highest 8 bits.
Fixes: dfcffb128be4 ("xen/arm32: SPSR_hy
On 11.06.2021 12:41, Julien Grall wrote:
> On Fri, 11 Jun 2021, 11:16 Jan Beulich, wrote:
>
>> On 11.06.2021 10:00, Julien Grall wrote:
>>> On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote:
>>>
The Arm ARM's description of MSR doesn't even allow for plain "SPSR"
here, and while gas accept
On Fri, 11 Jun 2021, 11:16 Jan Beulich, wrote:
> On 11.06.2021 10:00, Julien Grall wrote:
> > On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote:
> >
> >> The Arm ARM's description of MSR doesn't even allow for plain "SPSR"
> >> here, and while gas accepts this, it takes it to mean SPSR_cf. Yet
> >>
flight 162605 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
This commit is dedicated to fix incorrect convertion from
cpu_addr to page address in cases when we get virtual
address which allocated throught xen_swiotlb_alloc_coherent()
and can be mapped in the vmalloc range.
As the result, virt_to_page() cannot convert this address
properly and return incorre
This confuses disassemblers, at the very least. Move
.altinstr_replacement to .init.text, dropping the redundant ALIGN().
Also, to have .altinstr_replacement have consistent attributes in the
object files, add "x" to the one instance where it was missing.
Signed-off-by: Jan Beulich
---
I'm uncer
flight 162636 xen-unstable-smoke real [real]
flight 162640 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162636/
http://logs.test-lab.xenproject.org/osstest/logs/162640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
This confuses disassemblers, at the very least. When this data still
lived in .init.*, this probably didn't matter much, albeit the
"#execinstr" would have been suspicious to me already then. But the
latest with their movement to .rodata these attributes should have been
dropped.
Fixes: 9cbe093b7b
On 11.06.2021 10:00, Julien Grall wrote:
> On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote:
>
>> The Arm ARM's description of MSR doesn't even allow for plain "SPSR"
>> here, and while gas accepts this, it takes it to mean SPSR_cf. Yet
>> surely all of SPSR wants updating on this path, not just the
flight 162632 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162632/
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
On Fri, 11 Jun 2021, 08:55 Jan Beulich, wrote:
> The Arm ARM's description of MSR doesn't even allow for plain "SPSR"
> here, and while gas accepts this, it takes it to mean SPSR_cf. Yet
> surely all of SPSR wants updating on this path, not just the lowest and
> highest 8 bits.
>
Can you provide
The Arm ARM's description of MSR doesn't even allow for plain "SPSR"
here, and while gas accepts this, it takes it to mean SPSR_cf. Yet
surely all of SPSR wants updating on this path, not just the lowest and
highest 8 bits.
Fixes: dfcffb128be4 ("xen/arm32: SPSR_hyp/SPSR")
Signed-off-by: Jan Beulic
flight 162604 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162604/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162346
test-amd64-i386-xl-qemut-win7-amd64 19
On 11.06.2021 03:49, Stefano Stabellini wrote:
> In any case, I tried to figure it out. I guessed it could be a compiler
> error. I followed the white rabbit down the ARM ARM hole. I disassebled
> the Xen binary [1] from the failed job. "msr SPSR, r11" is 0x0026a38c.
>
> The encoding should be at
flight 162609 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162609/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
Am Fri, 11 Jun 2021 09:07:24 +0200
schrieb Juergen Gross :
> Isn't that a bug in fillup or the related rpm-macro?
No. Fillup expects a certain pattern: a bunch of comments and a single key=var
right after that. With such format it might be able to adjust the comment and
leave the key=var as it
On 11.06.21 07:46, Olaf Hering wrote:
Am Fri, 11 Jun 2021 07:01:31 +0200
schrieb Juergen Gross :
Why? You realize that above is a comment just documenting the default?
That depends on the context. See
https://bugzilla.opensuse.org/show_bug.cgi?id=1185682 for a reason why it
should become an
58 matches
Mail list logo
