[PATCH 11/11] xen-blkback: use bdev_discard_alignment
Use bdev_discard_alignment to calculate the correct discard alignment
offset even for partitions instead of just looking at the queue limit.
Also switch to use bdev_discard_granularity to get rid of the last direct
queue reference in xen_blkbk_discard.
Signed-off-by: Christoph Hellwig
---
drivers/block/xen-blkback/xenbus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index b21bffc9c50bc..04c90cb8955f6 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -583,14 +583,14 @@ static void xen_blkbk_discard(struct xenbus_transaction
xbt, struct backend_info
if (bdev_max_discard_sectors(bdev)) {
err = xenbus_printf(xbt, dev->nodename,
"discard-granularity", "%u",
- q->limits.discard_granularity);
+ bdev_discard_granularity(bdev));
if (err) {
dev_warn(>dev, "writing discard-granularity (%d)",
err);
return;
}
err = xenbus_printf(xbt, dev->nodename,
"discard-alignment", "%u",
- q->limits.discard_alignment);
+ bdev_discard_alignment(bdev));
if (err) {
dev_warn(>dev, "writing discard-alignment (%d)",
err);
return;
--
2.30.2
[PATCH 10/11] rnbd-srv: use bdev_discard_alignment
Use bdev_discard_alignment to calculate the correct discard alignment
offset even for partitions instead of just looking at the queue limit.
Signed-off-by: Christoph Hellwig
---
drivers/block/rnbd/rnbd-srv-dev.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/rnbd/rnbd-srv-dev.h
b/drivers/block/rnbd/rnbd-srv-dev.h
index d080a0de59225..4309e52524691 100644
--- a/drivers/block/rnbd/rnbd-srv-dev.h
+++ b/drivers/block/rnbd/rnbd-srv-dev.h
@@ -59,7 +59,7 @@ static inline int rnbd_dev_get_discard_granularity(const
struct rnbd_dev *dev)
static inline int rnbd_dev_get_discard_alignment(const struct rnbd_dev *dev)
{
- return bdev_get_queue(dev->bdev)->limits.discard_alignment;
+ return bdev_discard_alignment(dev->bdev);
}
#endif /* RNBD_SRV_DEV_H */
--
2.30.2
[PATCH 08/11] loop: remove a spurious clear of discard_alignment
The loop driver never sets a discard_alignment, so it also doens't need
to clear it to zero.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 976cf987b3920..61b642b966a08 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -789,7 +789,6 @@ static void loop_config_discard(struct loop_device *lo)
blk_queue_max_discard_sectors(q, 0);
blk_queue_max_write_zeroes_sectors(q, 0);
}
- q->limits.discard_alignment = 0;
}
struct loop_worker {
--
2.30.2
[PATCH 06/11] raid5: don't set the discard_alignment queue limit
The discard_alignment queue limit is named a bit misleading means the offset into the block device at which the discard granularity starts. Setting it to the discard granularity as done by raid5 is mostly harmless but also useless. Signed-off-by: Christoph Hellwig --- drivers/md/raid5.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 59f91e392a2ae..39b0afdf40d0a 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -7749,7 +7749,6 @@ static int raid5_run(struct mddev *mddev) */ stripe = stripe * PAGE_SIZE; stripe = roundup_pow_of_two(stripe); - mddev->queue->limits.discard_alignment = stripe; mddev->queue->limits.discard_granularity = stripe; blk_queue_max_write_zeroes_sectors(mddev->queue, 0); -- 2.30.2
fix and cleanup discard_alignment handling
Hi all, the somewhat confusing name of the discard_alignment queue limit, that really is an offset for the discard granularity mislead a lot of driver authors to set it to an incorrect value. This series tries to fix up all these cases. Diffstat: arch/um/drivers/ubd_kern.c |1 - drivers/block/loop.c |1 - drivers/block/nbd.c|3 --- drivers/block/null_blk/main.c |1 - drivers/block/rnbd/rnbd-srv-dev.h |2 +- drivers/block/virtio_blk.c |7 --- drivers/block/xen-blkback/xenbus.c |4 ++-- drivers/md/dm-zoned-target.c |2 +- drivers/md/raid5.c |1 - drivers/nvme/host/core.c |1 - drivers/s390/block/dasd_fba.c |1 - 11 files changed, 8 insertions(+), 16 deletions(-)
[PATCH 04/11] virtio_blk: fix the discard_granularity and discard_alignment queue limits
The discard_alignment queue limit is named a bit misleading means the
offset into the block device at which the discard granularity starts.
On the other hand the discard_sector_alignment from the virtio 1.1 looks
similar to what Linux uses as discard granularity (even if not very well
described):
"discard_sector_alignment can be used by OS when splitting a request
based on alignment. "
And at least qemu does set it to the discard granularity.
So stop setting the discard_alignment and use the virtio
discard_sector_alignment to set the discard granularity.
Fixes: 1f23816b8eb8 ("virtio_blk: add discard and write zeroes support")
Signed-off-by: Christoph Hellwig
---
drivers/block/virtio_blk.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 6ccf15253dee1..d624cc8eddc3c 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -867,11 +867,12 @@ static int virtblk_probe(struct virtio_device *vdev)
blk_queue_io_opt(q, blk_size * opt_io_size);
if (virtio_has_feature(vdev, VIRTIO_BLK_F_DISCARD)) {
- q->limits.discard_granularity = blk_size;
-
virtio_cread(vdev, struct virtio_blk_config,
discard_sector_alignment, );
- q->limits.discard_alignment = v ? v << SECTOR_SHIFT : 0;
+ if (v)
+ q->limits.discard_granularity = v << SECTOR_SHIFT;
+ else
+ q->limits.discard_granularity = blk_size;
virtio_cread(vdev, struct virtio_blk_config,
max_discard_sectors, );
--
2.30.2
[PATCH 02/11] nbd: don't set the discard_alignment queue limit
The discard_alignment queue limit is named a bit misleading means the
offset into the block device at which the discard granularity starts.
Setting it to the discard granularity as done by nbd is mostly harmless
but also useless.
Signed-off-by: Christoph Hellwig
---
drivers/block/nbd.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 4729aef8c6462..102597a4277b9 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -333,7 +333,6 @@ static int nbd_set_size(struct nbd_device *nbd, loff_t
bytesize,
if (nbd->config->flags & NBD_FLAG_SEND_TRIM) {
nbd->disk->queue->limits.discard_granularity = blksize;
- nbd->disk->queue->limits.discard_alignment = blksize;
blk_queue_max_discard_sectors(nbd->disk->queue, UINT_MAX);
}
blk_queue_logical_block_size(nbd->disk->queue, blksize);
@@ -1316,7 +1315,6 @@ static void nbd_config_put(struct nbd_device *nbd)
nbd->tag_set.timeout = 0;
nbd->disk->queue->limits.discard_granularity = 0;
- nbd->disk->queue->limits.discard_alignment = 0;
blk_queue_max_discard_sectors(nbd->disk->queue, 0);
mutex_unlock(>config_lock);
@@ -1781,7 +1779,6 @@ static struct nbd_device *nbd_dev_add(int index, unsigned
int refs)
blk_queue_flag_set(QUEUE_FLAG_NONROT, disk->queue);
blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, disk->queue);
disk->queue->limits.discard_granularity = 0;
- disk->queue->limits.discard_alignment = 0;
blk_queue_max_discard_sectors(disk->queue, 0);
blk_queue_max_segment_size(disk->queue, UINT_MAX);
blk_queue_max_segments(disk->queue, USHRT_MAX);
--
2.30.2
[PATCH 01/11] ubd: don't set the discard_alignment queue limit
The discard_alignment queue limit is named a bit misleading means the
offset into the block device at which the discard granularity starts.
Setting it to the discard granularity as done by ubd is mostly harmless
but also useless.
Signed-off-by: Christoph Hellwig
---
arch/um/drivers/ubd_kern.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index 085ffdf98e57e..c4344b67628dd 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -799,7 +799,6 @@ static int ubd_open_dev(struct ubd *ubd_dev)
}
if (ubd_dev->no_trim == 0) {
ubd_dev->queue->limits.discard_granularity = SECTOR_SIZE;
- ubd_dev->queue->limits.discard_alignment = SECTOR_SIZE;
blk_queue_max_discard_sectors(ubd_dev->queue, UBD_MAX_REQUEST);
blk_queue_max_write_zeroes_sectors(ubd_dev->queue,
UBD_MAX_REQUEST);
}
--
2.30.2
[PATCH 05/11] dm-zoned: don't set the discard_alignment queue limit
The discard_alignment queue limit is named a bit misleading means the offset into the block device at which the discard granularity starts. Setting it to the discard granularity as done by dm-zoned is mostly harmless but also useless. Signed-off-by: Christoph Hellwig --- drivers/md/dm-zoned-target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-zoned-target.c b/drivers/md/dm-zoned-target.c index cac295cc8840e..0ec5d8b9b1a4e 100644 --- a/drivers/md/dm-zoned-target.c +++ b/drivers/md/dm-zoned-target.c @@ -1001,7 +1001,7 @@ static void dmz_io_hints(struct dm_target *ti, struct queue_limits *limits) blk_limits_io_min(limits, DMZ_BLOCK_SIZE); blk_limits_io_opt(limits, DMZ_BLOCK_SIZE); - limits->discard_alignment = DMZ_BLOCK_SIZE; + limits->discard_alignment = 0; limits->discard_granularity = DMZ_BLOCK_SIZE; limits->max_discard_sectors = chunk_sectors; limits->max_hw_discard_sectors = chunk_sectors; -- 2.30.2
[PATCH 09/11] nvme: remove a spurious clear of discard_alignment
The nvme driver never sets a discard_alignment, so it also doens't need to clear it to zero. Signed-off-by: Christoph Hellwig --- drivers/nvme/host/core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index b9b0fbde97c80..76a9ccd5d064a 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1628,7 +1628,6 @@ static void nvme_config_discard(struct gendisk *disk, struct nvme_ns *ns) BUILD_BUG_ON(PAGE_SIZE / sizeof(struct nvme_dsm_range) < NVME_DSM_MAX_RANGES); - queue->limits.discard_alignment = 0; queue->limits.discard_granularity = size; /* If discard is already enabled, don't reset queue limits */ -- 2.30.2
[PATCH 07/11] dasd: don't set the discard_alignment queue limit
The discard_alignment queue limit is named a bit misleading means the offset into the block device at which the discard granularity starts. Setting it to PAGE_SIZE while the discard granularity is the block size that is smaller or the same as PAGE_SIZE as done by dasd is mostly harmless but also useless. Signed-off-by: Christoph Hellwig --- drivers/s390/block/dasd_fba.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/s390/block/dasd_fba.c b/drivers/s390/block/dasd_fba.c index 8bd5665db9198..60be7f7bf2d16 100644 --- a/drivers/s390/block/dasd_fba.c +++ b/drivers/s390/block/dasd_fba.c @@ -782,7 +782,6 @@ static void dasd_fba_setup_blk_queue(struct dasd_block *block) blk_queue_segment_boundary(q, PAGE_SIZE - 1); q->limits.discard_granularity = logical_block_size; - q->limits.discard_alignment = PAGE_SIZE; /* Calculate max_discard_sectors and make it PAGE aligned */ max_bytes = USHRT_MAX * logical_block_size; -- 2.30.2
[PATCH 03/11] null_blk: don't set the discard_alignment queue limit
The discard_alignment queue limit is named a bit misleading means the offset into the block device at which the discard granularity starts. Setting it to the discard granularity as done by null_blk is mostly harmless but also useless. Signed-off-by: Christoph Hellwig --- drivers/block/null_blk/main.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c index 5cb4c92cdffea..a521e914a9843 100644 --- a/drivers/block/null_blk/main.c +++ b/drivers/block/null_blk/main.c @@ -1765,7 +1765,6 @@ static void null_config_discard(struct nullb *nullb) } nullb->q->limits.discard_granularity = nullb->dev->blocksize; - nullb->q->limits.discard_alignment = nullb->dev->blocksize; blk_queue_max_discard_sectors(nullb->q, UINT_MAX >> 9); } -- 2.30.2
[ovmf test] 169501: regressions - FAIL
flight 169501 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169501/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 48 days 472 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 48 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169500: regressions - FAIL
flight 169500 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169500/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 48 days 471 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 47 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169498: regressions - FAIL
flight 169498 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169498/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 48 days 470 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 46 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [PATCH v7 04/20] kernel: Add combined power-off+restart handler call chain API
On 4/15/22 21:14, Rafael J. Wysocki wrote:
> Honestly, I would prefer this to be split so as to make it easier to
> review if nothing else.
I'll try to split it in v8.
> On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko
> wrote:
>>
>> SoC platforms often have multiple ways of how to perform system's
>> power-off and restart operations. Meanwhile today's kernel is limited to
>> a single option. Add combined power-off+restart handler call chain API,
>> which is inspired by the restart API. The new API provides both power-off
>> and restart functionality.
>>
>> The old pm_power_off method will be kept around till all users are
>> converted to the new API.
>>
>> Current restart API will be replaced by the new unified API since
>> new API is its superset. The restart functionality of the sys-off handler
>> API is built upon the existing restart-notifier APIs.
>
> Which means that the existing notifier chains for system restart are
> used as they are without modifications.
>
> At least that's what follows from the code and it would be good to
> mention it here.
Will improve the commit message.
> Moreover, a new notifier chain is introduced for the power-off case
> and it appears to be the counterpart of the restart_handler_list
> chain, but then why is it blocking and not atomic like the latter?
Good catch, it probably indeed should be atomic because shutting down
could run with a disabled interrupts. I'll invistigate this more for v8,
at least right now I don't recall any particular reason for using the
blocking notifier.
>> In order to ease conversion to the new API, convenient helpers are added
>> for the common use-cases. They will reduce amount of boilerplate code and
>> remove global variables. These helpers preserve old behaviour for cases
>> where only one power-off handler is expected, this is what all existing
>> drivers want, and thus, they could be easily converted to the new API.
>> Users of the new API should explicitly enable power-off chaining by
>> setting corresponding flag of the power_handler structure.
>
> "the corresponding"
Thanks
>> Signed-off-by: Dmitry Osipenko
>> ---
>> include/linux/reboot.h | 229 ++-
>> kernel/power/hibernate.c | 2 +-
>> kernel/reboot.c | 604 ++-
>> 3 files changed, 827 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/linux/reboot.h b/include/linux/reboot.h
>> index a2429648d831..ba5e5dddcfcd 100644
>> --- a/include/linux/reboot.h
>> +++ b/include/linux/reboot.h
>> @@ -8,10 +8,35 @@
>>
>> struct device;
>>
>> -#define SYS_DOWN 0x0001 /* Notify of system down */
>> -#define SYS_RESTARTSYS_DOWN
>> -#define SYS_HALT 0x0002 /* Notify of system halt */
>> -#define SYS_POWER_OFF 0x0003 /* Notify of system power off */
>> +enum reboot_prepare_mode {
>> + SYS_DOWN = 1, /* Notify of system down */
>> + SYS_RESTART = SYS_DOWN,
>> + SYS_HALT, /* Notify of system halt */
>> + SYS_POWER_OFF, /* Notify of system power off */
>> +};
>> +
>> +/*
>> + * Standard restart priority levels. Intended to be set in the
>> + * sys_off_handler.restart_priority field.
>> + *
>> + * Use `RESTART_PRIO_ABC +- prio` style for additional levels.
>> + *
>> + * RESTART_PRIO_RESERVED: Falls back to RESTART_PRIO_DEFAULT.
>> + * Drivers may leave priority initialized
>> + * to zero, to auto-set it to the default level.
>
> What is the "default level" here?
"default level" = RESTART_PRIO_DEFAULT = 128
I'll remove the second sentence about the "default level", for clarity.
>> + *
>> + * RESTART_PRIO_LOW: Use this for handler of last resort.
>> + *
>> + * RESTART_PRIO_DEFAULT: Use this for default/generic handler.
>> + *
>> + * RESTART_PRIO_HIGH: Use this if you have multiple handlers and
>> + * this handler has higher priority than the
>> + * default handler.
>> + */
>> +#define RESTART_PRIO_RESERVED 0
>> +#define RESTART_PRIO_LOW 8
>> +#define RESTART_PRIO_DEFAULT 128
>> +#define RESTART_PRIO_HIGH 192
>>
>> enum reboot_mode {
>> REBOOT_UNDEFINED = -1,
>> @@ -49,6 +74,201 @@ extern int register_restart_handler(struct
>> notifier_block *);
>> extern int unregister_restart_handler(struct notifier_block *);
>> extern void do_kernel_restart(char *cmd);
>>
>> +/*
>> + * System power-off and restart API.
>> + */
>> +
>> +/*
>> + * Standard power-off priority levels. Intended to be set in the
>> + * sys_off_handler.power_off_priority field.
>> + *
>> + * Use `POWEROFF_PRIO_ABC +- prio` style for additional levels.
>
> What exactly does this mean?
"POWEROFF_PRIO_DEFAULT+1 or POWEROFF_PRIO_DEFAULT-1" for example, I'll
improve it in v8.
>> + *
>> + * POWEROFF_PRIO_RESERVED: Falls back to POWEROFF_PRIO_DEFAULT.
>> + *
Re: [PATCH v7 03/20] reboot: Print error message if restart handler has duplicated priority
On 4/14/22 14:19, Rafael J. Wysocki wrote:
> On Thu, Apr 14, 2022 at 12:24 AM Dmitry Osipenko
> wrote:
>>
>> On 4/13/22 21:48, Rafael J. Wysocki wrote:
>>> On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko
>>> wrote:
Add sanity check which ensures that there are no two restart handlers
registered using the same priority. This requirement will become mandatory
once all drivers will be converted to the new API and such errors will be
fixed.
Signed-off-by: Dmitry Osipenko
>>>
>>> The first two patches in the series are fine with me and there's only
>>> one minor nit regarding this one (below).
>>>
---
kernel/reboot.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/kernel/reboot.c b/kernel/reboot.c
index ed4e6dfb7d44..acdae4e95061 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -182,6 +182,21 @@ static ATOMIC_NOTIFIER_HEAD(restart_handler_list);
*/
int register_restart_handler(struct notifier_block *nb)
{
+ int ret;
+
+ ret =
atomic_notifier_chain_register_unique_prio(_handler_list, nb);
+ if (ret != -EBUSY)
+ return ret;
+
+ /*
+* Handler must have unique priority. Otherwise call order is
+* determined by registration order, which is unreliable.
+*
+* This requirement will become mandatory once all drivers
+* will be converted to use new sys-off API.
+*/
+ pr_err("failed to register restart handler using unique
priority\n");
>>>
>>> I would use pr_info() here, because this is not a substantial error AFAICS.
>>
>> It's indeed not a substantial error so far, but it will become
>> substantial later on once only unique priorities will be allowed. The
>> pr_warn() could be a good compromise here, pr_info() is too mild, IMO.
>
> Well, I'm still unconvinced about requiring all of the users of this
> interface to use unique priorities.
>
> Arguably, there are some of them who don't really care about the
> ordering, so could there be an option for them to specify the lack of
> care by, say, passing 0 as the priority that would be regarded as a
> special case?
>
> IOW, if you pass 0, you'll be run along the others who've also passed
> 0, but if you pass anything different from 0, it must be unique. What
> do you think?
There are indeed cases where ordering is unimportant. Like a case of
PMIC and watchdog restart handlers for example, both handlers will
produce equal effect from a user's perspective. Perhaps indeed it's more
practical to have at least one shared level.
In this patchset the level 0 is specified as an alias to the default
level 128. If one user registers handler using unique level 128 and the
other user uses non-unique level 0, then we have ambiguity.
One potential option is to make the whole default level 128 non-unique.
This will allow users to not care about the uniqueness by default like
they always did it previously, but it will hide potential problems for
users who actually need unique level and don't know about it yet due to
a lucky registration ordering that they have today. Are you okay with
this option?
[ovmf test] 169497: regressions - FAIL
flight 169497 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169497/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 469 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 45 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
RE: [PATCH V5 1/2] xen/arm: Add i.MX lpuart driver
> Subject: Re: [PATCH V5 1/2] xen/arm: Add i.MX lpuart driver > > On Thu, 14 Apr 2022, Peng Fan (OSS) wrote: > > From: Peng Fan > > > > The i.MX LPUART Documentation: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > nxp.com%2Fwebapp%2FDownload%3FcolCode%3DIMX8QMIECdata=04 > %7C01%7Cp > > > eng.fan%40nxp.com%7Caf595d02a1dd4ed5825b08da1f2f0e78%7C686ea1d3bc > 2b4c6 > > > fa92cd99c5c301635%7C0%7C0%7C637856584221931187%7CUnknown%7CTW > FpbGZsb3d > > > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > %7C > > > 3000sdata=3N2TsMqzhHF5dem1Cyeo2HVdgfTJFnPHSoMW7KrNph8%3D > rese > > rved=0 Chatper 13.6 Low Power Universal Asynchronous Receiver/ > > Transmitter (LPUART) > > > > Tested-by: Henry Wang > > Signed-off-by: Peng Fan > > --- > > xen/arch/arm/include/asm/imx-lpuart.h | 64 ++ > > xen/drivers/char/Kconfig | 7 + > > xen/drivers/char/Makefile | 1 + > > xen/drivers/char/imx-lpuart.c | 276 ++ > > 4 files changed, 348 insertions(+) > > create mode 100644 xen/arch/arm/include/asm/imx-lpuart.h > > create mode 100644 xen/drivers/char/imx-lpuart.c > > > > diff --git a/xen/arch/arm/include/asm/imx-lpuart.h > > b/xen/arch/arm/include/asm/imx-lpuart.h > > new file mode 100644 > > index 00..fe859045dc > > --- /dev/null > > +++ b/xen/arch/arm/include/asm/imx-lpuart.h > > @@ -0,0 +1,64 @@ > > +/* > > + * xen/arch/arm/include/asm/imx-lpuart.h > > + * > > + * Common constant definition between early printk and the LPUART > > +driver > > + * > > + * Peng Fan > > + * Copyright 2022 NXP > > + * > > + * This program is free software; you can redistribute it and/or > > +modify > > + * it under the terms of the GNU General Public License as published > > +by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + */ > > + > > +#ifndef __ASM_ARM_IMX_LPUART_H__ > > +#define __ASM_ARM_IMX_LPUART_H__ > > + > > +/* 32-bit register definition */ > > +#define UARTBAUD (0x10) > > +#define UARTSTAT (0x14) > > +#define UARTCTRL (0x18) > > +#define UARTDATA (0x1C) > > +#define UARTMATCH (0x20) > > +#define UARTMODIR (0x24) > > +#define UARTFIFO (0x28) > > +#define UARTWATER (0x2c) > > + > > +#define UARTSTAT_TDRE BIT(23, UL) > > +#define UARTSTAT_TC BIT(22, UL) > > +#define UARTSTAT_RDRF BIT(21, UL) > > +#define UARTSTAT_OR BIT(19, UL) > > + > > +#define UARTBAUD_OSR_SHIFT(24) > > +#define UARTBAUD_OSR_MASK (0x1f) > > +#define UARTBAUD_SBR_MASK (0x1fff) > > +#define UARTBAUD_BOTHEDGE (0x0002) > > +#define UARTBAUD_TDMAE(0x0080) > > +#define UARTBAUD_RDMAE(0x0020) > > + > > +#define UARTCTRL_TIE BIT(23, UL) > > +#define UARTCTRL_TCIE BIT(22, UL) > > +#define UARTCTRL_RIE BIT(21, UL) > > +#define UARTCTRL_ILIE BIT(20, UL) > > +#define UARTCTRL_TE BIT(19, UL) > > +#define UARTCTRL_RE BIT(18, UL) > > +#define UARTCTRL_MBIT(4, UL) > > + > > +#define UARTWATER_RXCNT_OFF 24 > > + > > +#endif /* __ASM_ARM_IMX_LPUART_H__ */ > > + > > +/* > > + * Local variables: > > + * mode: C > > + * c-file-style: "BSD" > > + * c-basic-offset: 4 > > + * indent-tabs-mode: nil > > + * End: > > + */ > > diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index > > 2ff5b288e2..e5f7b1d8eb 100644 > > --- a/xen/drivers/char/Kconfig > > +++ b/xen/drivers/char/Kconfig > > @@ -13,6 +13,13 @@ config HAS_CADENCE_UART > > This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq > > based board, say Y. > > > > +config HAS_IMX_LPUART > > + bool "i.MX LPUART driver" > > + default y > > + depends on ARM_64 > > + help > > + This selects the i.MX LPUART. If you have i.MX8QM based board, say Y. > > + > > config HAS_MVEBU > > bool "Marvell MVEBU UART driver" > > default y > > diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile > > index 7c646d771c..14e67cf072 100644 > > --- a/xen/drivers/char/Makefile > > +++ b/xen/drivers/char/Makefile > > @@ -8,6 +8,7 @@ obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o > > obj-$(CONFIG_HAS_OMAP) += omap-uart.o > > obj-$(CONFIG_HAS_SCIF) += scif-uart.o > > obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o > > +obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o > > obj-$(CONFIG_ARM) += arm-uart.o > > obj-y += serial.o > > obj-$(CONFIG_XEN_GUEST) += xen_pv_console.o diff --git > > a/xen/drivers/char/imx-lpuart.c b/xen/drivers/char/imx-lpuart.c new > > file mode 100644 index 00..df44f91e5d > > --- /dev/null > > +++ b/xen/drivers/char/imx-lpuart.c > > @@
[ovmf test] 169496: regressions - FAIL
flight 169496 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169496/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 468 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 44 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169494: regressions - FAIL
flight 169494 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169494/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 467 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 43 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[linux-linus test] 169488: tolerable FAIL - PUSHED
flight 169488 linux-linus real [real] flight 169493 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169488/ http://logs.test-lab.xenproject.org/osstest/logs/169493/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-freebsd12-amd64 19 guest-localmigrate/x10 fail pass in 169493-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169475 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169475 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169475 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169475 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169475 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169475 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail like 169475 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169475 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169475 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: linux3a69a44278a72e15f12e24f5db4d277a497649aa baseline version: linuxa2c29ccd9477861b16ddc02c411a6c9665250558 Last test of basis 169475 2022-04-17 03:22:21 Z0 days Testing same since 169488 2022-04-17 17:09:36 Z0 days1 attempts People who touched revisions under test: Andy Shevchenko Anna-Maria Behnsen Bjorn
[ovmf test] 169492: regressions - FAIL
flight 169492 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169492/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 466 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 42 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio devices in Xen guests
On 16.04.22 09:07, Christoph Hellwig wrote:
Hello Christoph
On Fri, Apr 15, 2022 at 03:02:45PM -0700, Stefano Stabellini wrote:
This makes sense overall. Considering that the swiotlb-xen case and the
virtio case are mutually exclusive, I would write it like this:
Curious question: Why can't the same grant scheme also be used for
non-virtio devices? I really hate having virtio hooks in the arch
dma code. Why can't Xen just say in DT/ACPI that grants can be used
for a given device?
In Xen system:
- the grants are not used for "non-virtualized" devices at all (platform
devices for the passthrough).
- the grants are widely used for "virtualized, but non-virtio" devices
(traditional Xen PV devices), but grants for these Xen PV devices
are used in a different way and *not* at the DMA ops level like in
current approach
Or I misunderstood your question?
This patch series tries to make things work with "virtio" devices in Xen
system without introducing any modifications to code under drivers/virtio.
We could avoid having virtio hooks in the arch DMA code, but we need to
trigger setting xen-virtio DMA ops for the virtio device from some other
place.
For example, the following code would also work, but requires altering
virtio_mmio_probe():
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 56128b9..8f48491 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -615,6 +615,9 @@ static int virtio_mmio_probe(struct platform_device
*pdev)
DMA_BIT_MASK(32 +
PAGE_SHIFT));
} else {
rc = dma_set_mask_and_coherent(>dev,
DMA_BIT_MASK(64));
+
+ if (arch_has_restricted_virtio_memory_access())
+ xen_virtio_setup_dma_ops(>dev);
}
if (rc)
rc = dma_set_mask_and_coherent(>dev,
DMA_BIT_MASK(32));
Another possible option could be to introduce local init function in
drivers/xen/xen-virtio.c to scan the device tree and set xen-virtio DMA
ops for all devices with the
"xen,dev-domid" property.
What do you think?
--
Regards,
Oleksandr Tyshchenko
[ovmf test] 169491: regressions - FAIL
flight 169491 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169491/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 465 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 41 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169490: regressions - FAIL
flight 169490 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169490/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 464 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 40 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio devices in Xen guests
On 16.04.22 01:02, Stefano Stabellini wrote:
Hello Stefano
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Call xen_virtio_setup_dma_ops() only for Xen-aware virtio devices
in Xen guests if restricted access to the guest memory is enabled.
Signed-off-by: Oleksandr Tyshchenko
---
include/xen/arm/xen-ops.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
index 621da05..28b2ad3 100644
--- a/include/xen/arm/xen-ops.h
+++ b/include/xen/arm/xen-ops.h
@@ -2,12 +2,19 @@
#ifndef _ASM_ARM_XEN_OPS_H
#define _ASM_ARM_XEN_OPS_H
+#include
#include
+#include
static inline void xen_setup_dma_ops(struct device *dev)
{
if (xen_swiotlb_detect())
dev->dma_ops = _swiotlb_dma_ops;
+
+#ifdef CONFIG_XEN_VIRTIO
+ if (arch_has_restricted_virtio_memory_access() &&
xen_is_virtio_device(dev))
+ xen_virtio_setup_dma_ops(dev);
+#endif
This makes sense overall.
thank you
Considering that the swiotlb-xen case and the
virtio case are mutually exclusive, I would write it like this:
if (arch_has_restricted_virtio_memory_access() &&
xen_is_virtio_device(dev))
xen_virtio_setup_dma_ops(dev);
else if (xen_swiotlb_detect())
dev->dma_ops = _swiotlb_dma_ops;
Agree, will do
There is no need for #ifdef (also see other comments).
Agree, if !CONFIG_XEN_VIRTIO then xen_virtio_ are just stubs.
#ifdef CONFIG_XEN_VIRTIO
void xen_virtio_setup_dma_ops(struct device *dev);
bool xen_is_virtio_device(struct device *dev);
#else
static inline void xen_virtio_setup_dma_ops(struct device *dev)
{
}
static inline bool xen_is_virtio_device(struct device *dev)
{
return false;
}
#endif /* CONFIG_XEN_VIRTIO */
--
Regards,
Oleksandr Tyshchenko
[ovmf test] 169489: regressions - FAIL
flight 169489 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169489/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 463 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 39 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [RFC PATCH 5/6] arm/xen: Introduce xen_setup_dma_ops()
On 16.04.22 01:02, Stefano Stabellini wrote:
Hello Stefano
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch introduces new helper and places it in new header.
The helper's purpose is to assign any Xen specific DMA ops in
a single place. For now, we deal with xen-swiotlb DMA ops only.
The subsequent patch will add xen-virtio DMA ops case.
Also re-use the xen_swiotlb_detect() check on Arm32.
Thanks for the patch, this is good to have in any case. I would move it
to the beginning of the series.
ok, will move
Signed-off-by: Oleksandr Tyshchenko
---
arch/arm/include/asm/xen/xen-ops.h | 1 +
arch/arm/mm/dma-mapping.c| 5 ++---
arch/arm64/include/asm/xen/xen-ops.h | 1 +
arch/arm64/mm/dma-mapping.c | 5 ++---
include/xen/arm/xen-ops.h| 13 +
5 files changed, 19 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 include/xen/arm/xen-ops.h
diff --git a/arch/arm/include/asm/xen/xen-ops.h
b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index ..8d2fa24
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1 @@
+#include
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 82ffac6..a1bf9dd 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -33,7 +33,7 @@
#include
#include
#include
-#include
+#include
#include "dma.h"
#include "mm.h"
@@ -2288,8 +2288,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base,
u64 size,
set_dma_ops(dev, dma_ops);
#ifdef CONFIG_XEN
- if (xen_initial_domain())
- dev->dma_ops = _swiotlb_dma_ops;
+ xen_setup_dma_ops(dev);
#endif
You can take this opportunity to also remove the #ifdef, by providing an
empty stub implemention of xen_setup_dma_ops for the !CONFIG_XEN case.
agree, will do
dev->archdata.dma_ops_setup = true;
}
diff --git a/arch/arm64/include/asm/xen/xen-ops.h
b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index ..8d2fa24
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1 @@
+#include
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 6719f9e..831e673 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -9,9 +9,9 @@
#include
#include
#include
-#include
#include
+#include
void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
@@ -53,7 +53,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64
size,
iommu_setup_dma_ops(dev, dma_base, dma_base + size - 1);
#ifdef CONFIG_XEN
- if (xen_swiotlb_detect())
- dev->dma_ops = _swiotlb_dma_ops;
+ xen_setup_dma_ops(dev);
#endif
same here
ok
}
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
new file mode 100644
index ..621da05
--- /dev/null
+++ b/include/xen/arm/xen-ops.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM_XEN_OPS_H
+#define _ASM_ARM_XEN_OPS_H
+
+#include
+
+static inline void xen_setup_dma_ops(struct device *dev)
+{
+ if (xen_swiotlb_detect())
+ dev->dma_ops = _swiotlb_dma_ops;
+}
+
+#endif /* _ASM_ARM_XEN_OPS_H */
--
2.7.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Oleksandr Tyshchenko
Re: [RFC PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer
On 16.04.22 09:05, Christoph Hellwig wrote: Hello Christoph On Thu, Apr 14, 2022 at 10:19:31PM +0300, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Various updates is a big indicator that the patch should be split further. Please do one change at a time, and fold updates to the previous patches in the series into those patches instead of fixing them up later. Sure, next (non-RFC) version will do things properly. -- Regards, Oleksandr Tyshchenko
Re: [RFC PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer
On 16.04.22 01:02, Stefano Stabellini wrote:
Hello Stefano
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
In the context of current patch do the following:
1. Update code to support virtio-mmio devices
2. Introduce struct xen_virtio_data and account passed virtio devices
(using list) as we need to store some per-device data
3. Add multi-page support for xen_virtio_dma_map(unmap)_page callbacks
4. Harden code against malicious backend
5. Change to use alloc_pages_exact() instead of __get_free_pages()
6. Introduce locking scheme to protect mappings (I am not 100% sure
whether per-device lock is really needed)
7. Handle virtio device's DMA mask
8. Retrieve the ID of backend domain from DT for virtio-mmio device
instead of hardcoding it.
Signed-off-by: Oleksandr Tyshchenko
---
arch/arm/xen/enlighten.c | 11 +++
drivers/xen/Kconfig | 2 +-
drivers/xen/xen-virtio.c | 200 ++-
include/xen/xen-ops.h| 5 ++
4 files changed, 196 insertions(+), 22 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ec5b082..870d92f 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -409,6 +409,17 @@ int __init arch_xen_unpopulated_init(struct resource **res)
}
#endif
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ if (IS_ENABLED(CONFIG_XEN_HVM_VIRTIO_GRANT) && xen_hvm_domain())
+ return 1;
Instead of xen_hvm_domain(), you can just use xen_domain(). Also there
is no need for the #ifdef
CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, given that:
CONFIG_XEN_HVM_VIRTIO_GRANT depends on XEN_VIRTIO which selects
ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
Yes, but please see my comments in commit #2 regarding
CONFIG_XEN_HVM_VIRTIO_GRANT option and
arch_has_restricted_virtio_memory_access() on Arm.
I propose to have the following on Arm:
int arch_has_restricted_virtio_memory_access(void)
{
return xen_has_restricted_virtio_memory_access();
}
where common xen.h contain a helper to be used by both Arm and x86:
static inline int xen_has_restricted_virtio_memory_access(void)
{
if (IS_ENABLED(CONFIG_XEN_VIRTIO) && (xen_pv_domain() ||
xen_hvm_domain()))
return 1;
return 0;
}
But I would be happy with what you propose as well.
+ return 0;
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
+
static void __init xen_dt_guest_init(void)
{
struct device_node *xen_node;
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index fc61f7a..56afe6a 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -347,7 +347,7 @@ config XEN_VIRTIO
config XEN_HVM_VIRTIO_GRANT
bool "Require virtio for fully virtualized guests to use grant mappings"
- depends on XEN_VIRTIO && X86_64
+ depends on XEN_VIRTIO && (X86_64 || ARM || ARM64)
you can remove the architectural dependencies
According to the conversation in commit #2 we are considering just a
single XEN_VIRTIO option, but it is going to has the
same architectural dependencies: (X86_64 || ARM || ARM64)
By removing the architectural dependencies here, we will leave also
X86_32 covered (neither XEN_HVM_VIRTIO_GRANT nor XEN_PV_VIRTIO covered
it). I don't know whether it is ok or not.
Shall I remove dependencies anyway?
default y
help
Require virtio for fully virtualized guests to use grant mappings.
diff --git a/drivers/xen/xen-virtio.c b/drivers/xen/xen-virtio.c
index cfd5eda..c5b2ec9 100644
--- a/drivers/xen/xen-virtio.c
+++ b/drivers/xen/xen-virtio.c
@@ -7,12 +7,26 @@
#include
#include
+#include
#include
#include
#include
#include
#include
+struct xen_virtio_data {
+ /* The ID of backend domain */
+ domid_t dev_domid;
+ struct device *dev;
+ struct list_head list;
+ spinlock_t lock;
+ /* Is device behaving sane? */
+ bool broken;
If you moved "broken" after "dev_domid" we would save a few bytes for
every allocation due to padding.
ok, will do
Is data->lock only there to protect accesses to "broken"? If so, we
might not need it, but I am not sure.
Really good question, I introduced a lock for other purpose, I was
thinking we needed to protect grants allocation and removing, but wasn't
100% sure about it (I wrote a remark in commit description). But looking
into grant_table.c again I see that grant table code uses it's own lock,
so looks like we don't need an extra lock here. I need to re-check
regarding "broken", but likely we don't need here as well. If so, I will
remove the lock.
+};
+
+static LIST_HEAD(xen_virtio_devices);
+static DEFINE_SPINLOCK(xen_virtio_lock);
+
#define XEN_GRANT_ADDR_OFF0x8000ULL
static inline dma_addr_t grant_to_dma(grant_ref_t grant)
@@ -25,6 +39,25 @@
Re: [GIT PULL] xen: branch for v5.18-rc3
The pull request you sent on Sun, 17 Apr 2022 10:16:32 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-5.18-rc3-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a1901b464e7e3e28956ae7423db2847dbbfb5be8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [RFC PATCH 3/6] dt-bindings: xen: Add xen,dev-domid property description for xen-virtio layer
On 16.04.22 01:01, Stefano Stabellini wrote:
Hello Stefano
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Introduce Xen specific binding for the virtio-mmio device to be used
by Xen virtio support driver in a subsequent commit.
This binding specifies the ID of Xen domain where the corresponding
device (backend) resides. This is needed for the option to restrict
memory access using Xen grant mappings to work.
Signed-off-by: Oleksandr Tyshchenko
---
.../devicetree/bindings/virtio/xen,dev-domid.yaml | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/virtio/xen,dev-domid.yaml
diff --git a/Documentation/devicetree/bindings/virtio/xen,dev-domid.yaml
b/Documentation/devicetree/bindings/virtio/xen,dev-domid.yaml
new file mode 100644
index ..78be993
--- /dev/null
+++ b/Documentation/devicetree/bindings/virtio/xen,dev-domid.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/virtio/xen,dev-domid.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen specific binding for the virtio device
+
+maintainers:
+ - Oleksandr Tyshchenko
+
+select: true
+
+description:
+ This binding specifies the ID of Xen domain where the corresponding device
+ (backend) resides. This is needed for the option to restrict memory access
+ using Xen grant mappings to work.
+
+ Note that current and generic "iommus" bindings are mutually exclusive, since
+ the restricted memory access model on Xen behaves as a kind of software
IOMMU.
I don't think that this last statement is necessary or fully accurate, so
I would remove it.
ok, will remove
Other than that, this looks good to me.
thank you
+properties:
+ xen,dev-domid:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+ Should contain the ID of device's domain.
Maybe better as:
"The domid (domain ID) of the domain where the device (backend) is running"
ok, will change
+additionalProperties: true
+
+examples:
+ - |
+virtio_block@3000 {
+compatible = "virtio,mmio";
+reg = <0x3000 0x100>;
+interrupts = <41>;
+
+/* The device is located in Xen domain with ID 1 */
+xen,dev-domid = <1>;
+};
--
2.7.4
--
Regards,
Oleksandr Tyshchenko
Re: [RFC PATCH 2/6] virtio: add option to restrict memory access under Xen
On 16.04.22 01:01, Stefano Stabellini wrote:
Hello Stefano
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
From: Juergen Gross
In order to support virtio in Xen guests add a config option enabling
the user to specify whether in all Xen guests virtio should be able to
access memory via Xen grant mappings only on the host side.
This applies to fully virtualized guests only, as for paravirtualized
guests this is mandatory.
This requires to switch arch_has_restricted_virtio_memory_access()
from a pure stub to a real function on x86 systems (Arm systems are
not covered by now).
Add the needed functionality by providing a special set of DMA ops
handling the needed grant operations for the I/O pages.
Signed-off-by: Juergen Gross
---
arch/x86/mm/init.c| 15
arch/x86/mm/mem_encrypt.c | 5 --
arch/x86/xen/Kconfig | 9 +++
drivers/xen/Kconfig | 20 ++
drivers/xen/Makefile | 1 +
drivers/xen/xen-virtio.c | 177 ++
include/xen/xen-ops.h | 8 +++
7 files changed, 230 insertions(+), 5 deletions(-)
create mode 100644 drivers/xen/xen-virtio.c
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index d8cfce2..526a3b2 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -8,6 +8,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -1065,3 +1067,16 @@ unsigned long max_swapfile_size(void)
return pages;
}
#endif
+
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ if (IS_ENABLED(CONFIG_XEN_PV_VIRTIO) && xen_pv_domain())
+ return 1;
+ if (IS_ENABLED(CONFIG_XEN_HVM_VIRTIO_GRANT) && xen_hvm_domain())
+ return 1;
I think these two checks could be moved to a separate function in a Xen
header, e.g. xen_restricted_virtio_memory_access, and here you could
just
if (xen_restricted_virtio_memory_access())
return 1;
Agree, will do
+ return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+#endif
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 50d2099..dda020f 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -77,8 +77,3 @@ void __init mem_encrypt_init(void)
print_mem_encrypt_feature_info();
}
-int arch_has_restricted_virtio_memory_access(void)
-{
- return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
-}
-EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 85246dd..dffdffd 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -92,3 +92,12 @@ config XEN_DOM0
select X86_X2APIC if XEN_PVH && X86_64
help
Support running as a Xen Dom0 guest.
+
+config XEN_PV_VIRTIO
+ bool "Xen virtio support for PV guests"
+ depends on XEN_VIRTIO && XEN_PV
+ default y
+ help
+ Support virtio for running as a paravirtualized guest. This will
+ need support on the backend side (qemu or kernel, depending on the
+ virtio device types used).
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 120d32f..fc61f7a 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,4 +335,24 @@ config XEN_UNPOPULATED_ALLOC
having to balloon out RAM regions in order to obtain physical memory
space to create such mappings.
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ default n
+ depends on VIRTIO && DMA_OPS
+ select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+ help
+ Enable virtio support for running as Xen guest. Depending on the
+ guest type this will require special support on the backend side
+ (qemu or kernel, depending on the virtio device types used).
+
+config XEN_HVM_VIRTIO_GRANT
+ bool "Require virtio for fully virtualized guests to use grant mappings"
+ depends on XEN_VIRTIO && X86_64
+ default y
+ help
+ Require virtio for fully virtualized guests to use grant mappings.
+ This will avoid the need to give the backend the right to map all
+ of the guest memory. This will need support on the backend side
+ (qemu or kernel, depending on the virtio device types used).
I don't think we need 3 visible kconfig options for this.
In fact, I would only add one: XEN_VIRTIO. We can have any X86 (or ARM)
specific dependencies in the "depends" line under XEN_VIRTIO. And I
don't think we need XEN_HVM_VIRTIO_GRANT as a kconfig option
necessarely. It doesn't seem like some we want as build time option. At
most, it could be a runtime option (like a command line) or a debug
option (like an #define at the top of the source file.)
I don't know what was the initial idea of having and extra
XEN_HVM_VIRTIO and XEN_PV_VIRTIO options, but taking into the account that
they
[ovmf test] 169487: regressions - FAIL
flight 169487 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169487/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 462 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 38 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169486: regressions - FAIL
flight 169486 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169486/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 461 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 37 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169485: regressions - FAIL
flight 169485 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169485/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 460 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 36 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169484: regressions - FAIL
flight 169484 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169484/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 459 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 35 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[linux-linus test] 169475: tolerable FAIL - PUSHED
flight 169475 linux-linus real [real] flight 169483 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169475/ http://logs.test-lab.xenproject.org/osstest/logs/169483/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 169483-retest Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 169466 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169466 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169466 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169466 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169466 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169466 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169466 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169466 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169466 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass version targeted for testing: linuxa2c29ccd9477861b16ddc02c411a6c9665250558 baseline version: linux90ea17a9e27b5778ec517efb1ce0b81d36905654 Last test of basis 169466 2022-04-16 21:09:58 Z0 days Testing same since 169475 2022-04-17 03:22:21 Z0 days1 attempts People who touched revisions under
[ovmf test] 169482: regressions - FAIL
flight 169482 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169482/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 458 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 34 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169481: regressions - FAIL
flight 169481 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169481/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 47 days 457 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 33 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[libvirt test] 169477: regressions - FAIL
flight 169477 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/169477/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt 6be7beb3bdb9ad611a5598dad7edfbd2a836fd2e baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 646 days Failing since151818 2020-07-11 04:18:52 Z 645 days 627 attempts Testing same since 169415 2022-04-15 04:18:55 Z2 days3 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Moteen Shah Moteen Shah Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Praveen K Paladugu Richard W.M. Jones Ricky Tigg Robin Lee
[ovmf test] 169480: regressions - FAIL
flight 169480 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169480/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 47 days Failing since168258 2022-03-01 01:55:31 Z 47 days 456 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 32 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: xen-swiotlb issue when NVMe driver is enabled in Dom0 on ARM
Hi Stefano, > On 15 Apr 2022, at 6:40 pm, Stefano Stabellini wrote: > > On Fri, 15 Apr 2022, Christoph Hellwig wrote: >> On Thu, Apr 14, 2022 at 01:39:23PM -0700, Stefano Stabellini wrote: >>> OK, now we know that the code path with Xen is correct and it is the >>> same code path taken (dma_alloc_direct) as when !CONFIG_XEN and !SMMU. >>> That is how it should be. >>> >>> I cannot explain why dma_alloc_direct() would fail when called from >>> xen_swiotlb_alloc_coherent(), but it would succeed when called from >>> dma_alloc_attrs() without Xen. >>> >>> I am not aware of any restrictions that xen or swiotlb-xen would >>> introduce in that regard. Unless you are just running out of memory >>> because dom0_mem too low. >> >> The crash is deep down in the page allocator. Even if memory was low >> it should no crash. So there is some odd interaction between Xen >> and the page allocator going on. I think nvme and dma-direct really >> are only the messenger here. > > > I cannot think of anything but if that is the case I guess it is more > likely related to reserved-memory not properly advertised or ACPI tables > not properly populated. I am not sure if it is true as we are able to boot with the same reserved memory or the same ACPI table populated if we boot without swiotlb-xen dma ops. > > > Rahul, > > What happens if you boot Linux on Xen with swiotlb-xen disabled? Linux boots fine without any issue if we disable swiotlb-xen as mentioned below. > > > diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c > index 93e87b287556..26d9da58f2c6 100644 > --- a/arch/arm64/mm/dma-mapping.c > +++ b/arch/arm64/mm/dma-mapping.c > @@ -51,9 +51,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, > u64 size, > dev->dma_coherent = coherent; > if (iommu) > iommu_setup_dma_ops(dev, dma_base, size); > - > -#ifdef CONFIG_XEN > - if (xen_initial_domain()) > - dev->dma_ops = _swiotlb_dma_ops; > -#endif > } > > Regards, Rahul
[ovmf test] 169479: regressions - FAIL
flight 169479 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169479/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 47 days Failing since168258 2022-03-01 01:55:31 Z 47 days 455 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 31 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[xen-unstable test] 169472: tolerable FAIL
flight 169472 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/169472/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-pvhv2-amd 13 debian-fixup fail pass in 169444 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169444 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169444 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169444 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169444 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169444 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169444 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169444 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169444 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169444 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169444 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169444 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169444 test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass version
[GIT PULL] xen: branch for v5.18-rc3
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.18-rc3-tag xen: branch for v5.18-rc3 It contains just a single cleanup patch for the Xen balloon driver. Thanks. Juergen drivers/xen/balloon.c | 54 ++--- drivers/xen/unpopulated-alloc.c | 33 - 2 files changed, 23 insertions(+), 64 deletions(-) Juergen Gross (1): xen/balloon: don't use PV mode extra memory for zone device allocations
[ovmf test] 169478: regressions - FAIL
flight 169478 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169478/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 47 days Failing since168258 2022-03-01 01:55:31 Z 47 days 454 attempts Testing same since 169441 2022-04-16 00:41:39 Z1 days 30 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
