Hi, Stefano!
> We have the same thing in xen_swiotlb_free_coherent. Can we find a way
> to call cpu_addr_to_page() from xen_swiotlb_free_coherent?
> Maybe we can make cpu_addr_to_page non-static?
Yes, right, If we want to reuse this helper instead of the same code
block in xen_swiotlb_free_cohere
> This looks like it wasn't picked up? Should it go in rc1?
Hi, Konrad!
This looks like an unambiguous bug, and should be in rc1.
Cheers!
ср, 14 июл. 2021 г. в 03:15, Konrad Rzeszutek Wilk :
>
> On Tue, Jun 22, 2021 at 04:34:14PM +0300, Roman Skakun wrote:
> > This commit is dedicated to fix in
All,
the releases are due in a couple of weeks time (and 4.14.3 is
supposed to follow another few weeks later). Please point out backports
you find missing from the respective staging branches, but which you
consider relevant.
Please note that 4.13.4 is going to be the last Xen Project
coordinate
Andrew,
On 15.07.2021 09:58, Jan Beulich wrote:
> the releases are due in a couple of weeks time (and 4.14.3 is
> supposed to follow another few weeks later). Please point out backports
> you find missing from the respective staging branches, but which you
> consider relevant.
>
> Please note tha
flight 163691 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163691/
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 163690 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 16 xen-boot/l1 fail REGR. vs. 163458
Tests which are fa
Hi Stefano,
> On 15 Jul 2021, at 00:48, Stefano Stabellini wrote:
>
> Add Dom0less to SUPPORT.md to clarify its support status. The feature is
> mature enough and small enough to make it security supported.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
On 20.05.2021 13:46, Jan Beulich wrote:
> On 25.02.2021 17:23, Paul Durrant wrote:
>> On 25/02/2021 14:00, Jan Beulich wrote:
>>> On 25.02.2021 13:11, Paul Durrant wrote:
On 25/02/2021 07:33, Jan Beulich wrote:
> On 24.02.2021 17:39, Paul Durrant wrote:
>> On 23/02/2021 16:29, Jan Beul
Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure
distributions are going to want to use the latest QEMU and latest Xen,
without needed to build two different QEMU binaries.
[XEN PATCH v2 0/8] Fix libxl with QEMU 6.0 + remove some more deprecated usages.
<20210511092810.13759-1-anth
Hi Jan,
On 15/07/2021 07:38, Jan Beulich wrote:
On 14.07.2021 20:16, Julien Grall wrote:
On 05/07/2021 16:18, Jan Beulich wrote:
Let's try to avoid giving the impression that 32-bit tool stacks are as
capable as 64-bit ones.
Would you be able to provide a few examples of the known issues in
Hi Stefano,
On 15/07/2021 00:48, Stefano Stabellini wrote:
Add Dom0less to SUPPORT.md to clarify its support status. The feature is
mature enough and small enough to make it security supported.
I would suggest to explain the restriction in the commit message (and
give a link to XSA-372 commit
I'm observing a deadlock every time I try to unplug a xen-blkfront
device. With 5.14-rc1+ the deadlock looks like:
[ 513.682405]
[ 513.686617] WARNING: possible recursive locking detected
[ 513.691020] 5.14.0-rc1+ #370 Not tainted
[ 513.694272]
flight 163704 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163704/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
On 15/07/2021 08:58, Jan Beulich wrote:
> All,
>
> the releases are due in a couple of weeks time (and 4.14.3 is
> supposed to follow another few weeks later). Please point out backports
> you find missing from the respective staging branches, but which you
> consider relevant.
I've got a queue of
On 15.07.2021 12:58, Andrew Cooper wrote:
> On 15/07/2021 08:58, Jan Beulich wrote:
>> All,
>>
>> the releases are due in a couple of weeks time (and 4.14.3 is
>> supposed to follow another few weeks later). Please point out backports
>> you find missing from the respective staging branches, but wh
On 15.07.2021 11:05, Julien Grall wrote:
> On 15/07/2021 07:38, Jan Beulich wrote:
>> On 14.07.2021 20:16, Julien Grall wrote:
>>> On 05/07/2021 16:18, Jan Beulich wrote:
Let's try to avoid giving the impression that 32-bit tool stacks are as
capable as 64-bit ones.
>>>
>>> Would you be a
flight 163694 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163694/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 163321
test-amd64-i386-x
On Thu, Jul 15, 2021 at 11:16:30AM +0200, Vitaly Kuznetsov wrote:
> I'm observing a deadlock every time I try to unplug a xen-blkfront
> device. With 5.14-rc1+ the deadlock looks like:
I did actually stumble over this a few days ago just from code
inspection. Below is what I come up with, can you
Christoph Hellwig writes:
> On Thu, Jul 15, 2021 at 11:16:30AM +0200, Vitaly Kuznetsov wrote:
>> I'm observing a deadlock every time I try to unplug a xen-blkfront
>> device. With 5.14-rc1+ the deadlock looks like:
>
> I did actually stumble over this a few days ago just from code
> inspection.
On Thu, Jul 15, 2021 at 03:17:37PM +0200, Vitaly Kuznetsov wrote:
> Christoph Hellwig writes:
>
> > On Thu, Jul 15, 2021 at 11:16:30AM +0200, Vitaly Kuznetsov wrote:
> >> I'm observing a deadlock every time I try to unplug a xen-blkfront
> >> device. With 5.14-rc1+ the deadlock looks like:
> >
>
Christoph Hellwig writes:
> On Thu, Jul 15, 2021 at 03:17:37PM +0200, Vitaly Kuznetsov wrote:
>> Christoph Hellwig writes:
>>
>> > On Thu, Jul 15, 2021 at 11:16:30AM +0200, Vitaly Kuznetsov wrote:
>> >> I'm observing a deadlock every time I try to unplug a xen-blkfront
>> >> device. With 5.14-r
Am Thu, 15 Jul 2021 09:58:24 +0200
schrieb Jan Beulich :
> Please point out backports you find missing from the respective staging
> branches, but which you consider relevant.
Depending on how green the CI is supposed to be:
76416c459c libfsimage: fix parentheses in macro parameters
e54c433adf
xen-blkfront has a weird protocol where close message from the remote
side can be delayed, and where hot removals are treated somewhat
differently from regular removals, all leading to potential NULL
pointer removals, and a del_gendisk from the block device release
method, which will deadlock. Fix
On 15.07.2021 16:11, Olaf Hering wrote:
> Am Thu, 15 Jul 2021 09:58:24 +0200
> schrieb Jan Beulich :
>
>> Please point out backports you find missing from the respective staging
>> branches, but which you consider relevant.
>
> Depending on how green the CI is supposed to be:
>
> 76416c459c lib
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also re
The backport dropped the hunk deleting the setup_clear_cpu_cap() for HLE/RTM,
but retained the hunk adding setup_force_cpu_cap().
Calling both force and clear on the same feature elicits an error, and clear
takes precedence, which breaks the part of the bufix which makes migration
from older versi
On 14.07.2021 22:37, Bobby Eshleman wrote:
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -16,6 +16,7 @@
> * GNU General Public License for more details.
> */
>
> +#include
I don't think this is needed here; instead I think ...
> @@ -41,7 +42,6 @@
> #include
> #include
On 14.07.2021 22:37, Bobby Eshleman wrote:
> The function debugger_trap_entry() is somewhat large for an inlined
> function. This commit moves debugger_trap_entry() into debugger.c and
> makes it not inlined.
>
> Signed-off-by: Bobby Eshleman
Acked-by: Jan Beulich
On 14.07.2021 22:37, Bobby Eshleman wrote:
> The function domain_pause_for_debugger() is conditionally compiled if
> CONFIG_CRASH_DEBUG=y. Instead of placing an extra #ifdef inside
> domain.c, this commit moves domain_pause_for_debugger() into
> x86/debugger.c which is only built by Kbuild given C
On 7/15/21 8:17 AM, Christoph Hellwig wrote:
> xen-blkfront has a weird protocol where close message from the remote
> side can be delayed, and where hot removals are treated somewhat
> differently from regular removals, all leading to potential NULL
> pointer removals, and a del_gendisk from the b
On 15.07.2021 17:10, Andrew Cooper wrote:
> The backport dropped the hunk deleting the setup_clear_cpu_cap() for HLE/RTM,
> but retained the hunk adding setup_force_cpu_cap().
>
> Calling both force and clear on the same feature elicits an error, and clear
> takes precedence,
Right, I particularl
flight 163706 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163706/
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 15/07/2021 16:39, Jan Beulich wrote:
> On 15.07.2021 17:10, Andrew Cooper wrote:
>> The backport dropped the hunk deleting the setup_clear_cpu_cap() for HLE/RTM,
>> but retained the hunk adding setup_force_cpu_cap().
>>
>> Calling both force and clear on the same feature elicits an error, and cl
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
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. The
only error to return presently is EINVAL if a page could not
be mapped.
Signed-off-by: Logan Gunthorpe
---
kernel/dma/direct.c | 2 +-
1 file changed, 1 insertio
Pass through appropriate error codes from iommu_dma_map_sg() now that
the error code will be passed through dma_map_sgtable().
Signed-off-by: Logan Gunthorpe
Cc: Joerg Roedel
Cc: Will Deacon
---
drivers/iommu/dma-iommu.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(
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
Hi,
This series is spun out and expanded from my work to add P2PDMA support
to DMA map operations[1].
The P2PDMA work requires distinguishing different error conditions in
a map_sg operation. dma_map_sgtable() already allows for returning an
error code (where as dma_map_sg() is only allowed to re
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 EINVAL.
Signed-off-by: Mar
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
The only errno to return is -ENODEV 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(+),
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
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
---
include/linux/dma-map-ops.h | 8 +++-
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.
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorpe
Cc: Niklas Schnelle
Cc: Gerald Schaefer
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: C
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
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/parisc/sba_iommu.c | 2 +-
2 files changed, 2
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.
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 -EINVAL.
Signed-off-by: Martin Olive
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.
Propagate the return of dma_mapping_error() up, if it is an errno.
sba_coalesce_chunks() may only presently fail if sba_alloc_range()
fails, which in turn only fails if the iommu is out of mapping
resou
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure,
so propagate any errors that may happen all the way up.
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorpe
Cc: Russell King
Cc: Thomas Bogendoerfer
---
arch/arm/mm/dma-mapping.c | 22
On Thu, Jul 15, 2021 at 10:45:28AM -0600, Logan Gunthorpe wrote:
> Hi,
>
> This series is spun out and expanded from my work to add P2PDMA support
> to DMA map operations[1].
>
> The P2PDMA work requires distinguishing different error conditions in
> a map_sg operation. dma_map_sgtable() already
On 2021-07-15 10:53 a.m., Russell King (Oracle) wrote:
> On Thu, Jul 15, 2021 at 10:45:28AM -0600, Logan Gunthorpe wrote:
>> Hi,
>>
>> This series is spun out and expanded from my work to add P2PDMA support
>> to DMA map operations[1].
>>
>> The P2PDMA work requires distinguishing different err
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 EINVAL.
ENOMEM is returned when no page tables ca
On 7/15/21 3:39 AM, Roman Skakun wrote:
>> This looks like it wasn't picked up? Should it go in rc1?
> Hi, Konrad!
>
> This looks like an unambiguous bug, and should be in rc1.
Looks like you didn't copy Christoph which could be part of the problem. Adding
him.
-boris
>
> Cheers!
>
> ср,
On Thu, Jul 15, 2021 at 12:58:53PM -0400, Boris Ostrovsky wrote:
>
> On 7/15/21 3:39 AM, Roman Skakun wrote:
> >> This looks like it wasn't picked up? Should it go in rc1?
> > Hi, Konrad!
> >
> > This looks like an unambiguous bug, and should be in rc1.
>
>
> Looks like you didn't copy Christoph
On 7/12/21 7:39 PM, Andrew Cooper wrote:
> On 12/07/2021 21:32, Daniel P. Smith wrote:
>> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
>> index ad3cddbf7d..a8805f514b 100644
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -747,16 +747,14 @@ extern int xsm_dt_policy
On 15/07/2021 08:58, Jan Beulich wrote:
> Beyond this I'd like the following to be considered:
>
> 6409210a5f51 libxencall: osdep_hypercall() should return long
> bef64f2c0019 libxencall: introduce variant of xencall2() returning long
> 01a2d001dea2 libxencall: Bump SONAME following new functionali
On 7/12/21 7:22 PM, Andrew Cooper wrote:
> On 12/07/2021 21:32, Daniel P. Smith wrote:
>> The flask XSM module provided the ability to switch from flask back to
>> the dummy XSM module during runtime. With this removal the only way to
>> switch between XSM modules is at boot time.
>>
>> Signed-off-
On 7/14/21 11:58 AM, Jan Beulich wrote:
> On 12.07.2021 22:32, Daniel P. Smith wrote:
>> The flask XSM module provided the ability to switch from flask back to
>> the dummy XSM module during runtime. With this removal the only way to
>> switch between XSM modules is at boot time.
>>
>> Signed-off-b
On 7/12/21 7:44 PM, Andrew Cooper wrote:
> On 12/07/2021 21:32, Daniel P. Smith wrote:
>> To reduce retpolines convert all the pointer function calls of the
>> xsm_ops hooks over to the alternative_call infrastructure.
>>
>> Signed-off-by: Daniel P. Smith
>> ---
>> xen/include/xsm/xsm.h | 195 +++
On 7/12/21 7:52 PM, Andrew Cooper wrote:
> On 12/07/2021 21:32, Daniel P. Smith wrote:
>> The generic event channel labeling has not been used by any XSM module since
>> its introduction. This commit removes the capability leaving FLASK labeling
>> field always present. In the future if a new XSM m
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xen
On 14/07/2021 21:37, Bobby Eshleman wrote:
> Currently, any architecture wishing to use common/ is likely
> to be required to implement the functions found in "asm/debugger.h".
> Some architectures, however, do not have an actual use for these
> functions and so are forced to implement stubs. This
flight 163709 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163709/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162891
test-amd64-amd64-qemuu-nested-am
Hello,
I /we /Vates would like to suggest some changes to the policy regarding the
enrollment to the pre-disclosure mailing list of the Xen Security Team.
We have had some talks with the French national CERT who has a need to be the
recipient of such a list. This national CERT -and in my experien
flight 163710 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163710/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162882
test-amd64-amd64-qemuu-nested-am
flight 163712 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163712/
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 15.07.2021 19:16, Andrew Cooper wrote:
> On 15/07/2021 08:58, Jan Beulich wrote:
>> Beyond this I'd like the following to be considered:
>>
>> 6409210a5f51 libxencall: osdep_hypercall() should return long
>> bef64f2c0019 libxencall: introduce variant of xencall2() returning long
>> 01a2d001dea2
On Thu, Jul 15, 2021 at 10:45:29AM -0600, Logan Gunthorpe wrote:
> + * dma_map_sgtable() will return the error code returned and convert
> + * a zero return (for legacy implementations) into -EINVAL.
> + *
> + * dma_map_sg() will always return zero on any negative or zero
> +
Careful here. What do all these errors from the low-level code mean
here? I think we need to clearly standardize on what we actually
return from ->map_sg and possibly document what the callers expect and
can do, and enforce that only those error are reported.
On Thu, Jul 15, 2021 at 10:45:42AM -0600, Logan Gunthorpe wrote:
> @@ -458,7 +460,7 @@ static int gart_map_sg(struct device *dev, struct
> scatterlist *sg, int nents,
> iommu_full(dev, pages << PAGE_SHIFT, dir);
> for_each_sg(sg, s, nents, i)
> s->dma_address = DMA_MAPPIN
On Thu, Jul 15, 2021 at 10:45:44AM -0600, Logan Gunthorpe wrote:
> @@ -194,6 +194,8 @@ static int __dma_map_sg_attrs(struct device *dev, struct
> scatterlist *sg,
> else
> ents = ops->map_sg(dev, sg, nents, dir, attrs);
>
> + WARN_ON_ONCE(ents == 0);
Turns this into a ne
flight 163711 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163711/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162550
test-amd64-amd64-xl-qemuu-win7-a
Ping?
On 02.07.21 16:29, Juergen Gross wrote:
The core of a pv linux guest produced via "xl dump-core" is not usable
as since kernel 4.14 only the linear p2m table is kept if Xen indicates
it is supporting that. Unfortunately xc_core_arch_map_p2m() is still
supporting the 3-level p2m tree only.
73 matches
Mail list logo
