On 28/07/2021 11:42, Ian Jackson wrote:
[CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
unless you have verified the sender and know the content is safe.
Jane Malalane writes ("[PATCH] xen/lib: Fix strcmp() and strncmp()"):
The C standard requires that each character
flight 164046 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164046/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164034
test-armhf-armhf-libvirt 16 sav
On Thu, Jul 29, 2021 at 10:37:35PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> struct pci_dev tracks the bound pci driver twice. This series is about
> removing this duplication.
>
> The first two patches are just cleanups. The third patch introduces a
> wrapper that abstracts access to struct pc
Hi Konrad:
Thanks for your review.
On 7/30/2021 12:29 AM, Konrad Rzeszutek Wilk wrote:
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1fa81c096c1d..6866e5784b53 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -194,8 +194,13 @@ static void swiotlb_init_io_tlb_
On 7/30/2021 12:05 AM, Dave Hansen wrote:
On 7/29/21 8:02 AM, Tianyu Lan wrote:
There is x86_hyper_type to identify hypervisor type and we may check
this variable after checking X86_FEATURE_HYPERVISOR.
static inline bool hv_is_isolation_supported(void)
{
if (!cpu_feature_enabled(X86_FEA
flight 164047 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164047/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 610bcc69ed3d1e8c016332a1862465d41d95dd6c
baseline version:
ovmf 514b3aa08ece52140b769
flight 164037 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164037/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR.
vs. 152332
test-amd
flight 164039 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164039/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 514b3aa08ece52140b769a8676595655691c7cb3
baseline version:
ovmf dc485c556d5f5db21debe
flight 164034 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164034/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 164014
Tests which did not succee
Hello,
struct pci_dev tracks the bound pci driver twice. This series is about
removing this duplication.
The first two patches are just cleanups. The third patch introduces a
wrapper that abstracts access to struct pci_dev->driver. In the next
patch (hopefully) all users are converted to use the
This prepares removing the driver member of struct pci_dev which holds the
same information than struct pci_dev::dev->driver.
Signed-off-by: Uwe Kleine-König
---
arch/powerpc/include/asm/ppc-pci.h| 3 +-
arch/powerpc/kernel/eeh_driver.c | 12 ---
arch/x86/events/int
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
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
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
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
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: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc
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.
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.
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
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: "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
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-
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
Hi,
This v3 of the series is spun out and expanded from my work to add
P2PDMA support to DMA map operations[1]. v2 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
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
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
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(+),
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
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.
Signed-off-by: Logan Gunthorpe
---
kernel/dma/mapping.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff -
flight 164030 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164030/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 163985
Tests which did not succeed, b
On Wed, Jul 28, 2021 at 10:52:25AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
> extra address space which is above shared_gpa_boundary
> (E.G 39 bit address line) reported by Hyper-V CPUID ISOLATION_CONFIG.
> The access phy
On 7/29/21 8:02 AM, Tianyu Lan wrote:
>>
>
> There is x86_hyper_type to identify hypervisor type and we may check
> this variable after checking X86_FEATURE_HYPERVISOR.
>
> static inline bool hv_is_isolation_supported(void)
> {
> if (!cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
> ret
On 29/07/2021 12:06, Julien Grall wrote:
From: Julien Grall
At the moment, do_control_lu() will set errno to 0 before calling
lu_arch() and then check errno. The expectation is nothing in lu_arch()
will change the value unless there is an error.
However, per errno(3), a function that succee
Hi Christoph:
Could you have a look at this patch and the following patch
"[PATCH 10/13] x86/Swiotlb: Add Swiotlb bounce buffer remap function
for HV IVM" These two patches follows your previous comments and add
dma_map_decrypted/dma_unmap_decrypted(). I don't add arch prefix because
each
On 7/29/2021 10:09 PM, Dave Hansen wrote:
On 7/29/21 6:01 AM, Tianyu Lan wrote:
On 7/29/2021 1:06 AM, Dave Hansen wrote:
On 7/28/21 7:52 AM, Tianyu Lan wrote:
@@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long
addr, int numpages, bool enc)
int ret;
/* Nothing t
On 7/29/21 6:01 AM, Tianyu Lan wrote:
> On 7/29/2021 1:06 AM, Dave Hansen wrote:
>> On 7/28/21 7:52 AM, Tianyu Lan wrote:
>>> @@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long
>>> addr, int numpages, bool enc)
>>> int ret;
>>> /* Nothing to do if memory encryption is
flight 164029 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164029/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 164019
test-amd64-amd64-qemuu-nested-amd 20
On 7/29/2021 1:06 AM, Dave Hansen wrote:
On 7/28/21 7:52 AM, Tianyu Lan wrote:
@@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long addr, int
numpages, bool enc)
int ret;
/* Nothing to do if memory encryption is not active */
- if (!mem_encrypt_active())
+
Hi Dave:
Thanks for your review.
On 7/28/2021 11:29 PM, Dave Hansen wrote:
On 7/28/21 7:52 AM, Tianyu Lan wrote:
@@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long addr, int
numpages, bool enc)
int ret;
/* Nothing to do if memory encryption is not active */
Hi Julien,
On 29.07.2021 13:20, Julien Grall wrote:
> Hi Michal,
>
> On 29/07/2021 11:42, Michal Orzel wrote:
>> According to ARMv8A architecture, AArch64 registers
>> are 64bit wide even though in many cases the upper
>> 32bit is reserved. Therefore there is no need for
>> function vreg_emulate_
Hi Michal,
On 29/07/2021 11:42, Michal Orzel wrote:
According to ARMv8A architecture, AArch64 registers
are 64bit wide even though in many cases the upper
32bit is reserved. Therefore there is no need for
function vreg_emulate_sysreg32 on arm64. This means
that we can have just one function vreg
From: Julien Grall
At the moment, do_control_lu() will set errno to 0 before calling
lu_arch() and then check errno. The expectation is nothing in lu_arch()
will change the value unless there is an error.
However, per errno(3), a function that succeeds is allowed to change
errno. In fact, syslog
From: Julien Grall
lu_start() will only set errno when it returns NULL. For all the
other cases, the value is unknown.
This means that when lu_start() returns an error message, it may not
be propagated to the client.
The check that errno is a non-zero value is now dropped and instead
the value
According to ARMv8A architecture, AArch64 registers
are 64bit wide even though in many cases the upper
32bit is reserved. Therefore there is no need for
function vreg_emulate_sysreg32 on arm64. This means
that we can have just one function vreg_emulate_sysreg
using new function pointer:
typedef boo
flight 164032 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164032/
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 29/07/2021 10:34, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 28.07.2021 16:59, Julien Grall wrote:
Hi Michal,
On 27/07/2021 10:50, Michal Orzel wrote:
According to ARMv8A architecture, AArch64 registers
are 64bit wide even though in many cases the upper
32bit is reserved. Therefore th
From: Julien Grall
The maximum path length supported by Xenstored protocol is
XENSTORE_ABS_PATH_MAX (i.e 3072). This doesn't take into account the
NUL at the end of the path.
However, the code to dump the nodes will allocate a buffer
of XENSTORE_ABS_PATH. As a result it may not be possible to li
Hi Julien,
On 28.07.2021 16:59, Julien Grall wrote:
> Hi Michal,
>
> On 27/07/2021 10:50, Michal Orzel wrote:
>> According to ARMv8A architecture, AArch64 registers
>> are 64bit wide even though in many cases the upper
>> 32bit is reserved. Therefore there is no need for
>> function vreg_emulate_
52 matches
Mail list logo
