flight 163020 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163020/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
flight 163017 qemu-mainline real [real]
flight 163023 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163017/
http://logs.test-lab.xenproject.org/osstest/logs/163023/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
It has become clear that an option to disable trapping SMC calls to Xen
is very useful for debugging user issues. Instead of having to provide a
patch to users every time, it would be great if we could just tell them
to add forward_smc=true to the Xen command line.
This option is obviously unsafe
On Fri, Jun 25, 2021 at 3:20 AM Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> > 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
flight 163018 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163018/
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
flight 163014 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163014/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 163004
test-armhf-armhf-libvirt 16
On Thu, Jun 24, 2021 at 11:58:57PM +0800, Claire Chang wrote:
> On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> > >
> > >
> > > On 6/24/2021 7:48 AM, Will Deacon wrote:
> > > > Ok, diff below which attempts to
On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> 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
flight 163016 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163016/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 93b29b886e8665e368598c711279d45b7e5d066c
baseline version:
xtf
flight 163019 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163019/
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
Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Ian Jackson
CC: Wei Liu
---
tools/libs/call/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/call/Makefile
On 6/21/21 2:53 AM, Jan Beulich wrote:
On 18.06.2021 18:35, Daniel P. Smith wrote:
On 6/18/21 7:53 AM, Andrew Cooper wrote:
On 18/06/2021 00:39, Daniel P. Smith wrote:
@@ -250,9 +261,8 @@ config XSM_FLASK_POLICY
If unsure, say Y.
config XSM_SILO
- def_bool y
+
On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> >
> >
> > On 6/24/2021 7:48 AM, Will Deacon wrote:
> > > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > > well. Qian Cai -- please can you try
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
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
Add the functions, swiotlb_{alloc,free} and is_swiotlb_for_alloc to
support the memory allocation from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and
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
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
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
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
drivers/of/address.c| 33 +
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 35 ---
On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
>
>
> On 6/24/2021 7:48 AM, Will Deacon wrote:
> > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > well. Qian Cai -- please can you try with these changes?
>
> This works fine.
Cool. Let me squash this patch
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 17 +
1 file
Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/iommu/dma-iommu.c | 12
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
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/base/core.c| 4
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14
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
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
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
kernel/dma/swiotlb.c | 50
On 09/06/2021 10:30, Jan Beulich wrote:
Failure here could in principle mean the device may still be issuing DMA
requests, which would continue to be translated by the page tables the
device entry currently points at. With this we cannot allow the
subsequent cleanup step of freeing the page
On 28.05.2021 08:56, Jan Beulich wrote:
> 1: expose SYSCFG, TOM, TOM2, and IORRs to Dom0
> 2: drop MSR_K7_HWCR
Any thoughts here?
Thanks, Jan
flight 163010 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163010/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
Hi Juergen,
On 24/06/2021 16:53, Juergen Gross wrote:
On 24.06.21 16:46, Julien Grall wrote:
From: Julien Grall
Commit 3adfb50315d9 ("tools/xenstored: Introduce a wrapper for
conn->funcs->can_{read, write}") consolidated the check
!conn->is_ignored in two new wrappers.
This means the check
On 24.06.21 16:46, Julien Grall wrote:
From: Julien Grall
Commit 3adfb50315d9 ("tools/xenstored: Introduce a wrapper for
conn->funcs->can_{read, write}") consolidated the check
!conn->is_ignored in two new wrappers.
This means the check in socket_can_process() is now redundant. In
fact it
From: Julien Grall
Commit 3adfb50315d9 ("tools/xenstored: Introduce a wrapper for
conn->funcs->can_{read, write}") consolidated the check
!conn->is_ignored in two new wrappers.
This means the check in socket_can_process() is now redundant. In
fact it should have been removed in orignal commit
On 6/24/2021 7:48 AM, Will Deacon wrote:
> Ok, diff below which attempts to tackle the offset issue I mentioned as
> well. Qian Cai -- please can you try with these changes?
This works fine.
>
> Will
>
> --->8
>
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index
flight 163015 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163015/
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
flight 163013 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163013/
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
flight 163007 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163007/
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
On Thu, Jun 24, 2021 at 12:34:09PM +0100, Robin Murphy wrote:
> On 2021-06-24 12:18, Will Deacon wrote:
> > On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
> > > On 2021-06-24 07:05, Claire Chang wrote:
> > > > On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
> > > > >
> >
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
> On 2021-06-24 07:05, Claire Chang wrote:
> > On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
> > >
> > > On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > > > is_swiotlb_force_bounce at
> > > >
On 24/06/2021 10:18, Julien Grall wrote:
Hi Juergen,
On 24/06/2021 10:17, Juergen Gross wrote:
On 24.06.21 10:12, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 11:23, Juergen Gross wrote:
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is
On 24/06/2021 13:02, Juergen Gross wrote:
On 24.06.21 12:46, Julien Grall wrote:
Hi Juergen,
On 24/06/2021 12:45, Juergen Gross wrote:
On 24.06.21 12:28, Julien Grall wrote:
Hi Juergen,
On 24/06/2021 10:41, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced
On 24.06.21 12:46, Julien Grall wrote:
Hi Juergen,
On 24/06/2021 12:45, Juergen Gross wrote:
On 24.06.21 12:28, Julien Grall wrote:
Hi Juergen,
On 24/06/2021 10:41, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, only Live-Update request can be
Hi Juergen,
On 24/06/2021 12:45, Juergen Gross wrote:
On 24.06.21 12:28, Julien Grall wrote:
Hi Juergen,
On 24/06/2021 10:41, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, only Live-Update request can be delayed. In a follow-up,
we will want to
Hi,
On 18/06/2021 11:59, Andrew Cooper wrote:
On 18/06/2021 01:12, Stefano Stabellini wrote:
On Thu, 17 Jun 2021, Daniel P. Smith wrote:
Would like to add myself as a reviewer for XSM.
Signed-off-by: Daniel P. Smith
Acked-by: Stefano Stabellini
Acked-by: Andrew Cooper
I have
On 24.06.21 12:28, Julien Grall wrote:
Hi Juergen,
On 24/06/2021 10:41, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, only Live-Update request can be delayed. In a follow-up,
we will want to delay more requests (e.g. transaction start).
Therefore
Hi,
On 22/06/2021 18:43, Julien Grall wrote:
Hi Oleksandr,
On 14/06/2021 21:18, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The "renesas,r8a77961" string identifies M3-W+ (aka M3-W ES3.0)
instead of "renesas,r8a7796" since Linux commit:
"9c9f7891093b02eb64ca4e1c7ab776a4296c058f
Hi,
On 16/06/2021 16:43, Julien Grall wrote:
From: Julien Grall
Hi all,
At the moment, Live-Update will, by default, not proceed if there are
in-flight transactions. It is possible force it by passing -F but this
will break any connection with in-flight transactions.
There are PV drivers
Hi Juergen,
On 24/06/2021 10:41, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, only Live-Update request can be delayed. In a follow-up,
we will want to delay more requests (e.g. transaction start).
Therefore we want to preserve delayed requests
flight 163004 xen-unstable real [real]
flight 163012 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163004/
http://logs.test-lab.xenproject.org/osstest/logs/163012/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective xen functions are being removed. The file_operations
structure fops is now being created by the helper macro
DEFINE_DRM_GEM_FOPS().
Signed-off-by: Thomas
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
At the moment, Live-Update will, by default, not proceed if there are
in-flight transactions. It is possible force it by passing -F but this
will break any connection with in-flight transactions.
There are PV drivers out that may never
On 24.06.21 10:42, Julien Grall wrote:
Hi Juergen,
On 24/06/2021 10:30, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, the restore code is considering the stream will contain at
most one in-flight request per connection. In a follow-up changes, we
flight 163009 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163009/
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
flight 163011 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163011/
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
Hi Juergen,
On 24/06/2021 10:30, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, the restore code is considering the stream will contain at
most one in-flight request per connection. In a follow-up changes, we
will want to transfer multiple in-flight
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, only Live-Update request can be delayed. In a follow-up,
we will want to delay more requests (e.g. transaction start).
Therefore we want to preserve delayed requests across Live-Update.
Delayed requests are just complete
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, the restore code is considering the stream will contain at
most one in-flight request per connection. In a follow-up changes, we
will want to transfer multiple in-flight requests.
The function read_state_buffered() is now
Hi Juergen,
On 24/06/2021 10:17, Juergen Gross wrote:
On 24.06.21 10:12, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 11:23, Juergen Gross wrote:
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it
On 24.06.21 10:12, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 11:23, Juergen Gross wrote:
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it (either on the same connection or from a different one).
Hi Juergen,
On 22/06/2021 11:23, Juergen Gross wrote:
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it (either on the same connection or from a different one).
Currently, this will crash xenstored
Hi Luca,
On 21/06/2021 10:55, Luca Fancellu wrote:
diff --git a/tools/xenstore/xenstored_control.h
b/tools/xenstore/xenstored_control.h
index 6842b8d88760..27d7f19e4b7f 100644
--- a/tools/xenstore/xenstored_control.h
+++ b/tools/xenstore/xenstored_control.h
@@ -20,3 +20,6 @@ int
On 24.06.21 09:56, Luca Fancellu wrote:
On 24 Jun 2021, at 08:34, Juergen Gross wrote:
On 24.06.21 09:32, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
call_delayed() is currently assuming that conn->in is NULL when
handling delayed request. However, the
Hi Juergen,
On 24/06/2021 09:44, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
delay_request() is currently assuming that the request delayed is
always conn->in. This is currently correct, but it is a call for
a latent bug as the function allows the caller to
> On 24 Jun 2021, at 08:34, Juergen Gross wrote:
>
> On 24.06.21 09:32, Juergen Gross wrote:
>> On 16.06.21 16:43, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> call_delayed() is currently assuming that conn->in is NULL when
>>> handling delayed request. However, the connection is not
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
delay_request() is currently assuming that the request delayed is
always conn->in. This is currently correct, but it is a call for
a latent bug as the function allows the caller to specify any request.
To prevent any future surprise,
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, the callbacks can_read and can_write are called directly. This
doesn't allow us to add generic check and therefore requires duplication.
At the moment, one check that could benefit to be common is whether the
connection
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
xenstored_core.h will consider live-udpate is not supported if
O_CLOEXEC doesn't exist. However, the header doesn't include the one
defining O_CLOEXEC (i.e. fcntl.h). This means that depending on
the header included, some source file
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
Currently, only liveupdate request can be delayed. The request can only
be performed by a privileged connection (e.g. dom0). So it is fine to
have no limits.
In a follow-up patch we will want to delay request for unprivileged
On 24.06.21 09:32, Juergen Gross wrote:
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
call_delayed() is currently assuming that conn->in is NULL when
handling delayed request. However, the connection is not paused.
Therefore new request can be processed and conn->in may be
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
call_delayed() is currently assuming that conn->in is NULL when
handling delayed request. However, the connection is not paused.
Therefore new request can be processed and conn->in may be non-NULL
if we have only received a partial
On 16.06.21 16:43, Julien Grall wrote:
From: Julien Grall
At the moment, dump_state_buffered_data() is taking two connections
in parameters (one is the connection to dump, the other is the
connection used to request LU). The naming doesn't help to
distinguish (c vs conn) them and this already
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch
> > here.
> >
>
74 matches
Mail list logo
