flight 163963 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163963/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
flight 163956 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163956/
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 163955 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163955/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 163321
test-armhf-armhf-xl-rtds
flight 163950 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163950/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
On Fri, Jul 23, 2021 at 08:10:28PM +, Andy Smith wrote:
> Hmm, I have the sector offset in the MD device so maybe I can
> convert that into a logical volume to know if a particular guest is
> provoking it…
So for anyone who ever wants to do that sort of thing:
# Find out offset that LVM puts
On Fri, 23 Jul 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 23/07/2021 00:36, Stefano Stabellini wrote:
> > If both legacy IOMMU bindings and generic bindings are present,
> > iommu_add_dt_device can be called twice. Do not return error in that
> > case, that way there is no need to check for -E
On Fri, 23 Jul 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 23/07/2021 17:42, Stefano Stabellini wrote:
> > On Fri, 23 Jul 2021, Julien Grall wrote:
> > > On 22/07/2021 22:39, Stefano Stabellini wrote:
> > > > On Thu, 22 Jul 2021, Julien Grall wrote:
> > > > > > You can go and edit 76085aff29f58
Hi Jan,
On Wed, Jul 21, 2021 at 04:49:26PM +0200, Jan Beulich wrote:
> On 21.07.2021 16:19, Andy Smith wrote:
> > I understand that below 4GiB memory use of swiotlb is disabled so
> > all the time previously this was not used, and now is. Perhaps the
> > bug is in there?
> >
> > I was told that t
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
In the case of a DMA_MAPPING_ERROR, -EIO is returned. Otherwise,
-ENOMEM or -EINVAL is returned depending on the error from
__map_sg_chunk().
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorp
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
pci_map_single_1() can fail for different reasons, but since the only
supported type of error return is DMA_MAPPING_ERROR, we coalesce those
errors into EIO.
ENOMEM is returned when no page tables can b
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
In the case of a dma_mapping_error() return -EIO as the actual cause
is opaque here.
sba_coalesce_chunks() may only presently fail if sba_alloc_range()
fails, which in turn only fails if the iommu is ou
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Propagate the error up if vio_dma_iommu_map_sg() fails.
ppc_iommu_map_sg() may fail either because of iommu_range_alloc() or
because of tbl->it_ops->set(). The former only supports returning an
error wi
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of the
->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Russell King
Cc: Thomas Bogendoerfer
---
arch
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc
Hi Stefano,
On 23/07/2021 17:42, Stefano Stabellini wrote:
On Fri, 23 Jul 2021, Julien Grall wrote:
On 22/07/2021 22:39, Stefano Stabellini wrote:
On Thu, 22 Jul 2021, Julien Grall wrote:
You can go and edit 76085aff29f585139a37a10ea0a7daa63f70872c to change
from 4K to any multiple of 4K, e.g
Convert to ssize_t return code so the return code from __iommu_map()
can be returned all the way down through dma_iommu_map_sg().
Signed-off-by: Logan Gunthorpe
Cc: Joerg Roedel
Cc: Will Deacon
---
drivers/iommu/iommu.c | 15 +++
include/linux/iommu.h | 22 +++---
2
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
vdma_alloc() may fail for different reasons, but since it only supports
indicating an error via a return of DMA_MAPPING_ERROR, we coalesce the
different reasons into -EIO as is documented on dma_map_sgta
Return appropriate error codes EINVAL or ENOMEM from
iommup_dma_map_sg(). If lower level code returns ENOMEM, then we
return it, other errors are coalesced into EINVAL.
iommu_dma_map_sg_swiotlb() returns -EIO as its an unknown error
from a call that returns DMA_MAPPING_ERROR.
Signed-off-by: Logan
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
So propagate the error from __s390_dma_map_sg() up. __s390_dma_map_sg()
returns either -ENOMEM on allocation failure or -EINVAL which is
the same as what's expected by dma_map_sgtable().
Signed-off-by:
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Niklas Schnelle
Cc: Gerald Schaefer
Cc: Heiko
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: "David S. Miller"
Cc: Niklas Schnelle
Cc: Mich
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav P
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Returning an errno from __sbus_iommu_map_sg() results in
sbus_iommu_map_sg_gflush() and sbus_iommu_map_sg_pflush() returning an
errno, as those functions are wrappers around __sbus_iommu_map_sg().
Signe
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
xen_swiotlb_map_sg() may only fail if xen_swiotlb_map_page() fails, but
xen_swiotlb_map_page() only supports returning errors as
DMA_MAPPING_ERROR. So coalesce all errors into EIO per the documentation
f
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Return -EINVAL if the ioc cannot be obtained.
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorpe
Cc: "James E.J. Bottomley"
Cc: Helge Deller
---
drivers/parisc/ccio-dma.c | 2 +-
drivers
Allow dma_map_sgtable() to pass errors from the map_sg() ops. This
will be required for returning appropriate error codes when mapping
P2PDMA memory.
Introduce __dma_map_sg_attrs() which will return the raw error code
from the map_sg operation (whether it be negative or zero). Then add a
dma_map_s
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
So make __dma_map_cont() return a valid errno (which is then propagated
to gart_map_sg() via dma_map_cont()) and return it in case of failure.
Also, return -EINVAL in case of invalid nents.
Signed-off-
Now that the map_sg() op expects error codes instead of return zero on
error, convert dma_direct_map_sg() to return an error code. Per the
documentation for dma_map_sgtable(), -EIO is returned due to an
DMA_MAPPING_ERROR with unknown cause.
Signed-off-by: Logan Gunthorpe
---
kernel/dma/direct.c
Hi,
This v2 of the series is spun out and expanded from my work to add
P2PDMA support to DMA map operations[1]. v1 is at [2]. The main changes
in v1 are to more carefully define the meaning of the error codes for
dma_map_sgtable().
The P2PDMA work requires distinguishing different error condition
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
The only errno to return is -EINVAL in the case when DMA is not
supported.
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorpe
---
kernel/dma/dummy.c | 2 +-
1 file changed, 1 insertion(+),
Now that all the .map_sg operations have been converted to returning
proper error codes, drop the code to handle a zero return value,
add a warning if a zero is returned and update the comment for the
map_sg operation.
Signed-off-by: Logan Gunthorpe
---
kernel/dma/mapping.c | 7 ---
1 file c
On Fri, 23 Jul 2021, Julien Grall wrote:
> On 22/07/2021 22:39, Stefano Stabellini wrote:
> > On Thu, 22 Jul 2021, Julien Grall wrote:
> > > > You can go and edit 76085aff29f585139a37a10ea0a7daa63f70872c to change
> > > > from 4K to any multiple of 4K, e.g. 8K, 12K, 16K, 20K. They should all
> > >
flight 163936 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163936/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs.
163321
test-amd64
flight 163945 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163945/
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
Hello Georges,
Le vendredi 23 juillet 2021 à 14:09 +0100, George Dunlap a écrit :
>
>
> On Mon, Jul 19, 2021 at 9:49 AM Charles-H. Schulz
> wrote:
> >
> > Jan Beulich @ 2021-07-19 08:44 CEST:
> >
> > > >
> > > > They act as a resource center for their downstreams, but the
> > information goes
> >
flight 163926 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163926/
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
test-amd64-i386-xl-
On Mon, Jul 19, 2021 at 9:49 AM Charles-H. Schulz
wrote:
>
> Jan Beulich @ 2021-07-19 08:44 CEST:
>
> >>
> >> They act as a resource center for their downstreams, but the
> information goes
> >> top down, i.e from the software developer to the downstream, not the
> >> opposite. Also how it entail
On 23.07.2021 11:28, Julien Grall wrote:
> Hi Jan,
>
> On 23/07/2021 07:31, Jan Beulich wrote:
>> On 23.07.2021 01:36, Stefano Stabellini wrote:
>>> --- a/xen/drivers/passthrough/device_tree.c
>>> +++ b/xen/drivers/passthrough/device_tree.c
>>> @@ -140,8 +140,13 @@ int iommu_add_dt_device(struct d
flight 163925 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163925/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 19 guest-start.2fail in 163888 pass in 163925
test-amd64-amd64-xl-qemuu-debian
flight 163929 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163929/
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
From: Alan Robinson
Add trailing blank to first part of concatenated string giving
"an emulated" instead of "anemulated".
Signed-off-by: Alan Robinson
---
tools/libs/light/libxl_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libs/light/libxl_dm.c b/tools/lib
Hi Jan,
On 23/07/2021 07:31, Jan Beulich wrote:
On 23.07.2021 01:36, Stefano Stabellini wrote:
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -140,8 +140,13 @@ int iommu_add_dt_device(struct dt_device_node *np)
if ( !ops )
return -EINV
Hi Stefano,
On 23/07/2021 00:36, Stefano Stabellini wrote:
If both legacy IOMMU bindings and generic bindings are present,
iommu_add_dt_device can be called twice. Do not return error in that
case, that way there is no need to check for -EEXIST at the call sites.
Remove the one existing -EEXIT c
Hi,
On 22/07/2021 22:39, Stefano Stabellini wrote:
On Thu, 22 Jul 2021, Julien Grall wrote:
You can go and edit 76085aff29f585139a37a10ea0a7daa63f70872c to change
from 4K to any multiple of 4K, e.g. 8K, 12K, 16K, 20K. They should all
work the same.
Looking at the boot logs on pastebin I notice
flight 163933 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163933/
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
45 matches
Mail list logo
