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
---
drive
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/rn
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/dr
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
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 |
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-targ
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 -
dri
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):
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 ---
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 100
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 us
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/m
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
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
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
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
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
>>
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
> 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%3DIMX8QMIEC
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
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
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-
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
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'
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
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
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: Oleks
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
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 dea
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
p
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 vir
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
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 o
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 X
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
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
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
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
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-
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
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
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-libvirt
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
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_allo
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
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
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 ++
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
48 matches
Mail list logo
