* Re: [PATCH V4 16/16] xfs: Define max extent length based on on-disk format definition
From: Chandan Babu R @ 2022-01-05 13:51 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs, david
In-Reply-To: <20220105004706.GT31583@magnolia>
On 05 Jan 2022 at 06:17, Darrick J. Wong wrote:
> On Tue, Dec 14, 2021 at 02:15:19PM +0530, Chandan Babu R wrote:
>> The maximum extent length depends on maximum block count that can be stored in
>> a BMBT record. Hence this commit defines MAXEXTLEN based on
>> BMBT_BLOCKCOUNT_BITLEN.
>>
>> While at it, the commit also renames MAXEXTLEN to XFS_MAX_BMBT_EXTLEN.
>>
>> Suggested-by: Darrick J. Wong <djwong@kernel.org>
>> Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
>> ---
>> fs/xfs/libxfs/xfs_alloc.c | 2 +-
>> fs/xfs/libxfs/xfs_bmap.c | 57 +++++++++++++++++-----------------
>> fs/xfs/libxfs/xfs_format.h | 21 +++++++------
>> fs/xfs/libxfs/xfs_inode_buf.c | 4 +--
>> fs/xfs/libxfs/xfs_trans_resv.c | 11 ++++---
>> fs/xfs/scrub/bmap.c | 2 +-
>> fs/xfs/xfs_bmap_util.c | 14 +++++----
>> fs/xfs/xfs_iomap.c | 28 ++++++++---------
>> 8 files changed, 72 insertions(+), 67 deletions(-)
>>
>> diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
>> index 353e53b892e6..3f9b9cbfef43 100644
>> --- a/fs/xfs/libxfs/xfs_alloc.c
>> +++ b/fs/xfs/libxfs/xfs_alloc.c
>> @@ -2493,7 +2493,7 @@ __xfs_free_extent_later(
>>
>> ASSERT(bno != NULLFSBLOCK);
>> ASSERT(len > 0);
>> - ASSERT(len <= MAXEXTLEN);
>> + ASSERT(len <= XFS_MAX_BMBT_EXTLEN);
>> ASSERT(!isnullstartblock(bno));
>> agno = XFS_FSB_TO_AGNO(mp, bno);
>> agbno = XFS_FSB_TO_AGBNO(mp, bno);
>
> Yessss another unprefixed constant goes away.
>
> <snip>
>
>> diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
>> index 3183f78fe7a3..dd5cffe63be3 100644
>> --- a/fs/xfs/libxfs/xfs_format.h
>> +++ b/fs/xfs/libxfs/xfs_format.h
>> @@ -885,15 +885,6 @@ enum xfs_dinode_fmt {
>> { XFS_DINODE_FMT_BTREE, "btree" }, \
>> { XFS_DINODE_FMT_UUID, "uuid" }
>>
>> -/*
>> - * Max values for extlen, extnum, aextnum.
>> - */
>> -#define MAXEXTLEN ((xfs_extlen_t)0x1fffff) /* 21 bits */
>> -#define XFS_MAX_EXTCNT_DATA_FORK ((xfs_extnum_t)0xffffffffffff) /* Unsigned 48-bits */
>> -#define XFS_MAX_EXTCNT_ATTR_FORK ((xfs_aextnum_t)0xffffffff) /* Unsigned 32-bits */
>> -#define XFS_MAX_EXTCNT_DATA_FORK_OLD ((xfs_extnum_t)0x7fffffff) /* Signed 32-bits */
>> -#define XFS_MAX_EXTCNT_ATTR_FORK_OLD ((xfs_aextnum_t)0x7fff) /* Signed 16-bits */
>> -
>> /*
>> * Inode minimum and maximum sizes.
>> */
>> @@ -1623,7 +1614,17 @@ typedef struct xfs_bmdr_block {
>> #define BMBT_BLOCKCOUNT_BITLEN 21
>>
>> #define BMBT_STARTOFF_MASK ((1ULL << BMBT_STARTOFF_BITLEN) - 1)
>> -#define BMBT_BLOCKCOUNT_MASK ((1ULL << BMBT_BLOCKCOUNT_BITLEN) - 1)
>> +
>> +/*
>> + * Max values for extlen and disk inode's extent counters.
>
> Nit: 'ondisk inode'
>
>
>> + */
>> +#define XFS_MAX_BMBT_EXTLEN ((xfs_extlen_t)(1ULL << BMBT_BLOCKCOUNT_BITLEN) - 1)
>> +#define XFS_MAX_EXTCNT_DATA_FORK ((xfs_extnum_t)0xffffffffffff) /* Unsigned 48-bits */
>> +#define XFS_MAX_EXTCNT_ATTR_FORK ((xfs_aextnum_t)0xffffffff) /* Unsigned 32-bits */
>> +#define XFS_MAX_EXTCNT_DATA_FORK_OLD ((xfs_extnum_t)0x7fffffff) /* Signed 32-bits */
>> +#define XFS_MAX_EXTCNT_ATTR_FORK_OLD ((xfs_aextnum_t)0x7fff) /* Signed 16-bits */
>> +
>> +#define BMBT_BLOCKCOUNT_MASK XFS_MAX_BMBT_EXTLEN
>
> Would this be simpler if XFS_MAX_EXTCNT* stay where they are, and only
> XFS_MAX_BMBT_EXTLEN moves down to be defined as an alias of
> BMBT_BLOCKCOUNT_MASK?
>
Yes, I think so. Also, all the *BMBT* macros defined around the same place
will probably help make the organization better.
--
chandan
^ permalink raw reply
* Re: [PATCH 2/2] Add common configuration field "queue_indirect_size"
From: Christian Schoenebeck @ 2022-01-05 13:52 UTC (permalink / raw)
To: Cornelia Huck; +Cc: virtio-comment, Stefan Hajnoczi, Greg Kurz
In-Reply-To: <87ilv13qgm.fsf@redhat.com>
On Montag, 3. Januar 2022 14:21:13 CET Cornelia Huck wrote:
> On Wed, Dec 29 2021, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > On Donnerstag, 23. Dezember 2021 12:03:50 CET Cornelia Huck wrote:
> >> On Wed, Dec 15 2021, Christian Schoenebeck <qemu_oss@crudebyte.com>
wrote:
> >> > On Dienstag, 14. Dezember 2021 18:20:28 CET Cornelia Huck wrote:
> >> >> Also, this is only for split ring; does packed ring need any updates?
> >> >
> >> > I have not reviewed the packed ring as much as I did the split ring, so
> >> > I
> >> > could not say reliably all the parts that shall be updated for the
> >> > packed
> >> > ring. There are some obvious parts like:
> >> >
> >> > 2.7.5 Scatter-Gather Support
> >> >
> >> > "The device limits the number of descriptors in a list through a
> >> > transport-
> >> > specific and/or device-specific value. If not limited, the maximum
> >> > number
> >> > of descriptors in a list is the virt queue size."
> >> >
> >> > However the question is, would anybody want large descriptor chains
> >> > with
> >> > the packaged ring in the first place? If I understand it correctly, the
> >> > benefits of the packed ring over the split ring only manifest for
> >> > devices
> >> > that interchange a very large number of rather small bulk data (e.g.
> >> > network devices), no?
> >>
> >> If we think that the feature does not make sense for packed ring, they
> >> should probably conflict with each other. Otherwise, I think we need at
> >> least a statement that the higher limit does not take effect for packed
> >> ring, or touch all the places where it would be relevant.
> >>
> >> What do others think?
> >
> > It would indeed be very useful if other people express their opinion about
> > this issue (packed ring scenario) as well before I continue on this issue.
> >
> > Probably the fact that my patches never made it through to the list were
> > not necessarily supporting this. Should I contact somebody regarding this
> > ML issue? Do members of the other ML also read this virtio-comment list?
> Yes, this situation is very unsatisfactory :( (I have contacted the
> people running this list, but there have not yet been any fixes...)
Only my emails with patches are refused by the list. All my other emails are
accepted. So not sure if the cause is really DKIM or something else. Maybe the
admins can suggest a workaround for me.
> Not sure which other lists would be appropriate to cc: -- maybe
> virtualization@lists.linux-foundation.org, but that one also suffers
> from DKIM issues :(
What I thought was wether subscribers of virtio-dev would typically read
virtio-comment as well. Because AFAICS people who more frequently deal with
virtio for their companies rather seem to post to virtio-dev.
> > I tried to compensate the current situation by updating the corresponding
> > issue description on Github in a very defailed and verbose way:
> > https://github.com/oasis-tcs/virtio-spec/issues/122
>
> Thanks. Hopefully me quoting this makes it more visible (I tried to
> quote more than I usually would in my other replies already...)
>
> Just to feature it more prominently for people who collapse quotes:
>
> https://github.com/oasis-tcs/virtio-spec/issues/122
>
> > If nobody replies early January, I would suggest to continue by ignoring
> > the packed ring. Because if somebody wants this for packed ring in
> > future, this can still be added to the specs without breaking things,
> > because this feature is negotiated per queue, not for the entire device.
>
> The problem is that we need to specify what is supposed to happen if
> packed ring *and* this feature are negotiated. If we do not want to add
> statements for the packed ring case, my suggestion would be
> - make packed ring and this feature mutually exclusive
> - add a new feature bit that works with packed ring later, if we think
> it is useful
Mja, I have to correct myself on that: I wrote in my previous email that this
was negotiated per queue. That's false of course as all virtio features are
currently negotiated for the entire device.
So you are right, if this new indirect size feature was negotiated then it
would apply to both a) split rings and b) packed rings a device might have.
Which is unfortunate.
Stefan, you are aware about this circumstance as well, right? Because I
remember we originally had a discussion on qemu-devel where you wanted to have
this configurable per queue, not per device.
Best regards,
Christian Schoenebeck
^ permalink raw reply
* Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
From: Russell King (Oracle) @ 2022-01-05 13:53 UTC (permalink / raw)
To: Jon Hunter
Cc: Ard Biesheuvel, Geert Uytterhoeven, Marek Szyprowski, Linux ARM,
Nicolas Pitre, Arnd Bergmann, Kees Cook, Keith Packard,
Linus Walleij, Nick Desaulniers, Tony Lindgren,
Krzysztof Kozlowski, Linux Samsung SOC, Linux-Renesas,
linux-tegra@vger.kernel.org
In-Reply-To: <4ae3e371-68d0-64d7-713e-88af45875b3f@nvidia.com>
On Wed, Jan 05, 2022 at 11:33:48AM +0000, Jon Hunter wrote:
> On 05/01/2022 11:12, Ard Biesheuvel wrote:
> > Thanks for the report.
> >
> > It would be helpful if you could provide some more context:
> > - does it happen on a LPAE build too?
> > - does it only happen on SMP capable systems?
>
> These are all SMP systems.
>
> > - does it reproduce on such systems when using only a single CPU?
> > (i.e., pass 'nosmp' on the kernel command line)
>
> I would need to try this.
Please note that I want an answer on the vmap stack patches by the
end of today (UK time - so about five hours after this email has
been sent) as we have only tonight and tomorrow's linux-next before
the probable opening of the merge window.
The options are:
1. The problem gets fixed today and I merge the fix today so it can
get tested in linux-next over the next few days by the various
build farms and test setups.
2. We postpone the merging of this until the very end of the merge
window to give more time to sort out this mess - but what it
means is keeping it in linux-next and keeping various platforms
broken during that period. However, this is really not fair for
other people, and some would say this isn't even an option.
3. We drop the entire series for this merge window, meaning it gets
dropped from linux-next, and have another go for the neext merge
window.
Sorry for being so demanding, but we're far too close to the merge
window to be trying to debug a feature that is clearly causing a
regression for several platforms.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH v1 01/34] ui: avoid compiler warnings from unused clipboard info variable
From: Alex Bennée @ 2022-01-05 13:49 UTC (permalink / raw)
To: qemu-devel
Cc: fam, berrange, Alex Bennée, Richard Henderson, f4bug,
Gerd Hoffmann, stefanha, crosa, pbonzini,
Philippe Mathieu-Daudé, aurelien
In-Reply-To: <20220105135009.1584676-1-alex.bennee@linaro.org>
From: Daniel P. Berrangé <berrange@redhat.com>
With latest clang 13.0.0 we get
../ui/clipboard.c:47:34: error: variable 'old' set but not used [-Werror,-Wunused-but-set-variable]
g_autoptr(QemuClipboardInfo) old = NULL;
^
The compiler can't tell that we only declared this variable in
order to get the side effect of free'ing it when out of scope.
This pattern is a little dubious for a use of g_autoptr, so
rewrite the code to avoid it.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
[AJB: fix merge conflict]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20211215141949.3512719-2-berrange@redhat.com>
---
ui/clipboard.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/ui/clipboard.c b/ui/clipboard.c
index 82572ea116..5f15cf853d 100644
--- a/ui/clipboard.c
+++ b/ui/clipboard.c
@@ -62,13 +62,11 @@ void qemu_clipboard_update(QemuClipboardInfo *info)
.type = QEMU_CLIPBOARD_UPDATE_INFO,
.info = info,
};
- g_autoptr(QemuClipboardInfo) old = NULL;
-
assert(info->selection < QEMU_CLIPBOARD_SELECTION__COUNT);
notifier_list_notify(&clipboard_notifiers, ¬ify);
- old = cbinfo[info->selection];
+ qemu_clipboard_info_unref(cbinfo[info->selection]);
cbinfo[info->selection] = qemu_clipboard_info_ref(info);
}
--
2.30.2
^ permalink raw reply related
* [PATCH v1 02/34] spice: Update QXLInterface for spice >= 0.15.0
From: Alex Bennée @ 2022-01-05 13:49 UTC (permalink / raw)
To: qemu-devel
Cc: fam, berrange, Philippe Mathieu-Daudé, f4bug,
Alex Bennée, Gerd Hoffmann, stefanha, crosa, pbonzini,
John Snow, aurelien
In-Reply-To: <20220105135009.1584676-1-alex.bennee@linaro.org>
From: John Snow <jsnow@redhat.com>
spice updated the spelling (and arguments) of "attache_worker" in
0.15.0. Update QEMU to match, preventing -Wdeprecated-declarations
compilations from reporting build errors.
See also:
https://gitlab.freedesktop.org/spice/spice/-/commit/974692bda1e77af92b71ed43b022439448492cb9
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20211215141949.3512719-3-berrange@redhat.com>
---
include/ui/qemu-spice.h | 6 ++++++
hw/display/qxl.c | 14 +++++++++++++-
ui/spice-display.c | 11 +++++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/ui/qemu-spice.h b/include/ui/qemu-spice.h
index 71ecd6cfd1..21fe195e18 100644
--- a/include/ui/qemu-spice.h
+++ b/include/ui/qemu-spice.h
@@ -40,6 +40,12 @@ int qemu_spice_migrate_info(const char *hostname, int port, int tls_port,
#define SPICE_NEEDS_SET_MM_TIME 0
#endif
+#if defined(SPICE_SERVER_VERSION) && (SPICE_SERVER_VERSION >= 0x000f00)
+#define SPICE_HAS_ATTACHED_WORKER 1
+#else
+#define SPICE_HAS_ATTACHED_WORKER 0
+#endif
+
#else /* CONFIG_SPICE */
#include "qemu/error-report.h"
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index e2d6e317da..1f9ad31943 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -517,13 +517,20 @@ static int qxl_track_command(PCIQXLDevice *qxl, struct QXLCommandExt *ext)
/* spice display interface callbacks */
-static void interface_attach_worker(QXLInstance *sin, QXLWorker *qxl_worker)
+static void interface_attached_worker(QXLInstance *sin)
{
PCIQXLDevice *qxl = container_of(sin, PCIQXLDevice, ssd.qxl);
trace_qxl_interface_attach_worker(qxl->id);
}
+#if !(SPICE_HAS_ATTACHED_WORKER)
+static void interface_attach_worker(QXLInstance *sin, QXLWorker *qxl_worker)
+{
+ interface_attached_worker(sin);
+}
+#endif
+
static void interface_set_compression_level(QXLInstance *sin, int level)
{
PCIQXLDevice *qxl = container_of(sin, PCIQXLDevice, ssd.qxl);
@@ -1131,7 +1138,12 @@ static const QXLInterface qxl_interface = {
.base.major_version = SPICE_INTERFACE_QXL_MAJOR,
.base.minor_version = SPICE_INTERFACE_QXL_MINOR,
+#if SPICE_HAS_ATTACHED_WORKER
+ .attached_worker = interface_attached_worker,
+#else
.attache_worker = interface_attach_worker,
+#endif
+
.set_compression_level = interface_set_compression_level,
#if SPICE_NEEDS_SET_MM_TIME
.set_mm_time = interface_set_mm_time,
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 1043f47f94..a3078adf91 100644
--- a/ui/spice-display.c
+++ b/ui/spice-display.c
@@ -500,10 +500,17 @@ void qemu_spice_display_refresh(SimpleSpiceDisplay *ssd)
/* spice display interface callbacks */
+#if SPICE_HAS_ATTACHED_WORKER
+static void interface_attached_worker(QXLInstance *sin)
+{
+ /* nothing to do */
+}
+#else
static void interface_attach_worker(QXLInstance *sin, QXLWorker *qxl_worker)
{
/* nothing to do */
}
+#endif
static void interface_set_compression_level(QXLInstance *sin, int level)
{
@@ -702,7 +709,11 @@ static const QXLInterface dpy_interface = {
.base.major_version = SPICE_INTERFACE_QXL_MAJOR,
.base.minor_version = SPICE_INTERFACE_QXL_MINOR,
+#if SPICE_HAS_ATTACHED_WORKER
+ .attached_worker = interface_attached_worker,
+#else
.attache_worker = interface_attach_worker,
+#endif
.set_compression_level = interface_set_compression_level,
#if SPICE_NEEDS_SET_MM_TIME
.set_mm_time = interface_set_mm_time,
--
2.30.2
^ permalink raw reply related
* [syzbot] WARNING in drm_atomic_helper_wait_for_vblanks
From: syzbot @ 2022-01-05 8:44 UTC (permalink / raw)
To: airlied, daniel, dri-devel, linux-kernel, maarten.lankhorst,
mripard, syzkaller-bugs, tzimmermann
Hello,
syzbot found the following issue on:
HEAD commit: 800829388818 mm: vmscan: reduce throttling due to a failur..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=158d5fc3b00000
kernel config: https://syzkaller.appspot.com/x/.config?x=35d2332e44a37812
dashboard link: https://syzkaller.appspot.com/bug?extid=b7db9fbc95be52cf485d
compiler: arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
userspace arch: arm
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b7db9fbc95be52cf485d@syzkaller.appspotmail.com
------------[ cut here ]------------
WARNING: CPU: 1 PID: 13058 at drivers/gpu/drm/drm_atomic_helper.c:1514 drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2b8 drivers/gpu/drm/drm_atomic_helper.c:1514
[CRTC:32:crtc-0] vblank wait timed out
Modules linked in:
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 13058 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0
Hardware name: ARM-Versatile Express
Backtrace:
[<816bd724>] (dump_backtrace) from [<816bd910>] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:237)
r7:81d53678 r6:82222be8 r5:60000093 r4:81d60e84
[<816bd8f8>] (show_stack) from [<816c6398>] (__dump_stack lib/dump_stack.c:88 [inline])
[<816bd8f8>] (show_stack) from [<816c6398>] (dump_stack_lvl+0x48/0x54 lib/dump_stack.c:106)
[<816c6350>] (dump_stack_lvl) from [<816c63bc>] (dump_stack+0x18/0x1c lib/dump_stack.c:113)
r5:00000000 r4:8243cd18
[<816c63a4>] (dump_stack) from [<816be3f0>] (panic+0x104/0x32c kernel/panic.c:232)
[<816be2ec>] (panic) from [<80241f08>] (__warn+0xa4/0x134 kernel/panic.c:603)
r3:8220c488 r2:00000000 r1:00000000 r0:81d53678
r7:00000009
[<80241e64>] (__warn) from [<816be6b4>] (warn_slowpath_fmt+0x9c/0xd4 kernel/panic.c:633)
r7:809265bc r6:000005ea r5:81dc58c0 r4:81dc5e60
[<816be61c>] (warn_slowpath_fmt) from [<809265bc>] (drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2b8 drivers/gpu/drm/drm_atomic_helper.c:1514)
r8:0000161b r7:00000000 r6:850c0cc0 r5:840dc050 r4:00000000
[<80926310>] (drm_atomic_helper_wait_for_vblanks.part.0) from [<80927bf4>] (drm_atomic_helper_wait_for_vblanks drivers/gpu/drm/drm_atomic_helper.c:1490 [inline])
[<80926310>] (drm_atomic_helper_wait_for_vblanks.part.0) from [<80927bf4>] (drm_atomic_helper_commit_tail+0x80/0x90 drivers/gpu/drm/drm_atomic_helper.c:1590)
r10:8421c15c r9:83f4c000 r8:00000000 r7:00000168 r6:f8c64d30 r5:83f4c000
r4:850c0cc0
[<80927b74>] (drm_atomic_helper_commit_tail) from [<8092873c>] (commit_tail+0x164/0x188 drivers/gpu/drm/drm_atomic_helper.c:1667)
r5:00000000 r4:850c0cc0
[<809285d8>] (commit_tail) from [<809290e8>] (drm_atomic_helper_commit drivers/gpu/drm/drm_atomic_helper.c:1884 [inline])
[<809285d8>] (commit_tail) from [<809290e8>] (drm_atomic_helper_commit+0x14c/0x170 drivers/gpu/drm/drm_atomic_helper.c:1817)
r9:83f4c000 r8:850c0cec r7:00000000 r6:83f4c000 r5:00000000 r4:850c0cc0
[<80928f9c>] (drm_atomic_helper_commit) from [<80949588>] (drm_atomic_commit+0x4c/0x58 drivers/gpu/drm/drm_atomic.c:1412)
r9:83f4c000 r8:840dc340 r7:00000001 r6:83f4c000 r5:850c0cc0 r4:00000000
[<8094953c>] (drm_atomic_commit) from [<80960b8c>] (drm_client_modeset_commit_atomic+0x200/0x248 drivers/gpu/drm/drm_client_modeset.c:1043)
r7:00000001 r6:00000001 r5:83f4c1ac r4:850c0cc0
[<8096098c>] (drm_client_modeset_commit_atomic) from [<80960cac>] (drm_client_modeset_commit_locked+0x64/0x18c drivers/gpu/drm/drm_client_modeset.c:1146)
r10:8220c44c r9:83f4c094 r8:81dcd740 r7:8411f818 r6:8411f800 r5:83f4c000
r4:83f4c000
[<80960c48>] (drm_client_modeset_commit_locked) from [<80960e00>] (drm_client_modeset_commit+0x2c/0x48 drivers/gpu/drm/drm_client_modeset.c:1172)
r9:83f4c094 r8:81dcd740 r7:8411f8b4 r6:00000000 r5:83f4c000 r4:8411f800
[<80960dd4>] (drm_client_modeset_commit) from [<80930dc4>] (__drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:252 [inline])
[<80960dd4>] (drm_client_modeset_commit) from [<80930dc4>] (__drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:231 [inline])
[<80960dd4>] (drm_client_modeset_commit) from [<80930dc4>] (drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:279 [inline])
[<80960dd4>] (drm_client_modeset_commit) from [<80930dc4>] (drm_fb_helper_lastclose drivers/gpu/drm/drm_fb_helper.c:2003 [inline])
[<80960dd4>] (drm_client_modeset_commit) from [<80930dc4>] (drm_fbdev_client_restore+0x5c/0x98 drivers/gpu/drm/drm_fb_helper.c:2403)
r5:823487f8 r4:8411f800
[<80930d68>] (drm_fbdev_client_restore) from [<809605e0>] (drm_client_dev_restore+0x7c/0xc8 drivers/gpu/drm/drm_client.c:226)
r7:83f4c0a8 r6:83f4c000 r5:83f4c06c r4:8411f800
[<80960564>] (drm_client_dev_restore) from [<80933b00>] (drm_lastclose drivers/gpu/drm/drm_file.c:467 [inline])
[<80960564>] (drm_client_dev_restore) from [<80933b00>] (drm_release+0x130/0x150 drivers/gpu/drm/drm_file.c:498)
r9:5ac3c35a r8:847bb610 r7:842190c0 r6:850c1900 r5:83f4c06c r4:83f4c000
[<809339d0>] (drm_release) from [<80487ed0>] (__fput+0x84/0x258 fs/file_table.c:280)
r7:82ccce58 r6:83932ba8 r5:000a201d r4:850c1900
[<80487e4c>] (__fput) from [<80488120>] (____fput+0x10/0x14 fs/file_table.c:313)
r9:5ac3c35a r8:836f8854 r7:8243d600 r6:836f8000 r5:836f8824 r4:00000000
[<80488110>] (____fput) from [<80266f04>] (task_work_run+0x8c/0xb8 kernel/task_work.c:164)
[<80266e78>] (task_work_run) from [<8020bff0>] (tracehook_notify_resume include/linux/tracehook.h:189 [inline])
[<80266e78>] (task_work_run) from [<8020bff0>] (do_work_pending+0x438/0x53c arch/arm/kernel/signal.c:630)
r9:5ac3c35a r8:80200244 r7:fffffe30 r6:80200244 r5:85195fb0 r4:836f8000
[<8020bbb8>] (do_work_pending) from [<80200088>] (slow_work_pending+0xc/0x20)
Exception stack(0x85195fb0 to 0x85195ff8)
5fa0: 00000000 00000002 00000000 00000003
5fc0: 00000004 01d844c0 0012bf94 00000006 00000000 0012bf88 00130240 00000000
5fe0: 2ce20000 7edf8348 000291dc 00029698 80000010 00000003
r10:00000006 r9:836f8000 r8:80200244 r7:00000006 r6:0012bf94 r5:01d844c0
r4:00000004
Rebooting in 86400 seconds..
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH 3/4] coresight: trbe: Work around the invalid prohibited states
From: Suzuki K Poulose @ 2022-01-05 13:54 UTC (permalink / raw)
To: Anshuman Khandual, linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Mathieu Poirier, coresight,
linux-doc, linux-kernel
In-Reply-To: <68961242-3d9b-a26d-3a0f-0d2ace04a17b@arm.com>
On 05/01/2022 11:16, Anshuman Khandual wrote:
>
>
> On 1/5/22 3:43 PM, Suzuki K Poulose wrote:
>> Hi Anshuman
>>
>> On 05/01/2022 05:05, Anshuman Khandual wrote:
>>> TRBE implementations affected by Arm erratum #2038923 might get TRBE into
>>> an inconsistent view on whether trace is prohibited within the CPU. As a
>>> result, the trace buffer or trace buffer state might be corrupted. This
>>> happens after TRBE buffer has been enabled by setting TRBLIMITR_EL1.E,
>>> followed by just a single context synchronization event before execution
>>> changes from a context, in which trace is prohibited to one where it isn't,
>>> or vice versa. In these mentioned conditions, the view of whether trace is
>>> prohibited is inconsistent between parts of the CPU, and the trace buffer
>>> or the trace buffer state might be corrupted.
>>>
>>> Work around this problem in the TRBE driver by preventing an inconsistent
>>> view of whether the trace is prohibited or not based on TRBLIMITR_EL1.E by
>>> immediately following a change to TRBLIMITR_EL1.E with at least one ISB
>>> instruction before an ERET, or two ISB instructions if no ERET is to take
>>> place. This adds a new cpu errata in arm64 errata framework and also
>>> updates TRBE driver as required.
>>>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Will Deacon <will@kernel.org>
>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
>>> Cc: coresight@lists.linaro.org
>>> Cc: linux-doc@vger.kernel.org
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>> ---
>>> Documentation/arm64/silicon-errata.rst | 2 +
>>> arch/arm64/Kconfig | 23 ++++++++++
>>> arch/arm64/kernel/cpu_errata.c | 9 ++++
>>> arch/arm64/tools/cpucaps | 1 +
>>> drivers/hwtracing/coresight/coresight-trbe.c | 47 +++++++++++++++-----
>>> 5 files changed, 72 insertions(+), 10 deletions(-)
>>
>> As with the previous patch, it may be a good idea to split the
>> patch to arm64 and trbe parts.
>
> Sure, will do.
>
>>
>>>
>>> diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
>>> index c9b30e6c2b6c..e0ef3e9a4b8b 100644
>>> --- a/Documentation/arm64/silicon-errata.rst
>>> +++ b/Documentation/arm64/silicon-errata.rst
>>> @@ -54,6 +54,8 @@ stable kernels.
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> | ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> +| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
>>> ++----------------+-----------------+-----------------+-----------------------------+
>>> | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 2105b68d88db..026e34fb6fad 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -796,6 +796,29 @@ config ARM64_ERRATUM_2064142
>>> If unsure, say Y.
>>> +config ARM64_ERRATUM_2038923
>>> + bool "Cortex-A510: 2038923: workaround TRBE corruption with enable"
>>> + depends on CORESIGHT_TRBE
>>> + default y
>>> + help
>>> + This option adds the workaround for ARM Cortex-A510 erratum 2038923.
>>> +
>>> + Affected Cortex-A510 core might cause an inconsistent view on whether trace is
>>> + prohibited within the CPU. As a result, the trace buffer or trace buffer state
>>> + might be corrupted. This happens after TRBE buffer has been enabled by setting
>>> + TRBLIMITR_EL1.E, followed by just a single context synchronization event before
>>> + execution changes from a context, in which trace is prohibited to one where it
>>> + isn't, or vice versa. In these mentioned conditions, the view of whether trace
>>> + is prohibited is inconsistent between parts of the CPU, and the trace buffer or
>>> + the trace buffer state might be corrupted.
>>> +
>>> + Work around this in the driver by preventing an inconsistent view of whether the
>>> + trace is prohibited or not based on TRBLIMITR_EL1.E by immediately following a
>>> + change to TRBLIMITR_EL1.E with at least one ISB instruction before an ERET, or
>>> + two ISB instructions if no ERET is to take place.
>>> +
>>> + If unsure, say Y.
>>> +
>>> config CAVIUM_ERRATUM_22375
>>> bool "Cavium erratum 22375, 24313"
>>> default y
>>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>>> index cbb7d5a9aee7..60b0c1f1d912 100644
>>> --- a/arch/arm64/kernel/cpu_errata.c
>>> +++ b/arch/arm64/kernel/cpu_errata.c
>>> @@ -607,6 +607,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>>> ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A510, 0, 0, 2)
>>> },
>>> #endif
>>> +#ifdef CONFIG_ARM64_ERRATUM_2038923
>>> + {
>>> + .desc = "ARM erratum 2038923",
>>> + .capability = ARM64_WORKAROUND_2038923,
>>> +
>>> + /* Cortex-A510 r0p0 - r0p2 */
>>> + ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A510, 0, 0, 2)
>>> + },
>>> +#endif
>>> {
>>> }
>>> };
>>> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
>>> index fca3cb329e1d..45a06d36d080 100644
>>> --- a/arch/arm64/tools/cpucaps
>>> +++ b/arch/arm64/tools/cpucaps
>>> @@ -56,6 +56,7 @@ WORKAROUND_1463225
>>> WORKAROUND_1508412
>>> WORKAROUND_1542419
>>> WORKAROUND_2064142
>>> +WORKAROUND_2038923
>>> WORKAROUND_TRBE_OVERWRITE_FILL_MODE
>>> WORKAROUND_TSB_FLUSH_FAILURE
>>> WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
>>> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
>>> index ec24b62b2cec..0689c6dab96d 100644
>>> --- a/drivers/hwtracing/coresight/coresight-trbe.c
>>> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
>>> @@ -92,11 +92,13 @@ struct trbe_buf {
>>> #define TRBE_WORKAROUND_OVERWRITE_FILL_MODE 0
>>> #define TRBE_WORKAROUND_WRITE_OUT_OF_RANGE 1
>>> #define TRBE_WORKAROUND_SYSREG_WRITE_FAILURE 2
>>> +#define TRBE_WORKAROUND_CORRUPTION_WITH_ENABLE 3
>>> static int trbe_errata_cpucaps[] = {
>>> [TRBE_WORKAROUND_OVERWRITE_FILL_MODE] = ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE,
>>> [TRBE_WORKAROUND_WRITE_OUT_OF_RANGE] = ARM64_WORKAROUND_TRBE_WRITE_OUT_OF_RANGE,
>>> [TRBE_WORKAROUND_SYSREG_WRITE_FAILURE] = ARM64_WORKAROUND_2064142,
>>> + [TRBE_WORKAROUND_CORRUPTION_WITH_ENABLE] = ARM64_WORKAROUND_2038923,
>>> -1, /* Sentinel, must be the last entry */
>>> };
>>> @@ -174,6 +176,11 @@ static inline bool trbe_may_fail_sysreg_write(struct trbe_cpudata *cpudata)
>>> return trbe_has_erratum(cpudata, TRBE_WORKAROUND_SYSREG_WRITE_FAILURE);
>>> }
>>> +static inline bool trbe_may_corrupt_with_enable(struct trbe_cpudata *cpudata)
>>> +{
>>
>> minor nit: trbe_needs_{ctxt_sync, isb}_after_enable() ?
>
> trbe_needs_ctxt_sync_after_enable() sounds better. Also will have to change
> the index above as well .. TRBE_NEEDS_CTXT_SYNC_AFTER_ENABLE.
>
>>
>>> + return trbe_has_erratum(cpudata, TRBE_WORKAROUND_CORRUPTION_WITH_ENABLE);
>>> +}
>>> +
>>> static int trbe_alloc_node(struct perf_event *event)
>>> {
>>> if (event->cpu == -1)
>>> @@ -187,6 +194,30 @@ static inline void trbe_drain_buffer(void)
>>> dsb(nsh);
>>> }
>>> +static inline void set_trbe_enabled(struct trbe_cpudata *cpudata)
>>> +{
>>> + u64 trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
>>
>> minor nit: This implies we do the TRBE programming in the following
>> manner in the common case (i.e, TRBE enabled in the beginning of a
>> session).
>> -> set TRBE LIMIT
>> -> read TRBE LIMIT
>> -> set TRBE ENABLED
>>
>> Could we please optimize this ? I believe the buf->trbe_limit
>> must hold the LIMITR value at any point in time. And thus this
>
> But is not bit risky though ! We have got the following places where
> given trbe_limit instance changes its value.
>
> drivers/../coresight-trbe.c: buf->trbe_limit = buf->trbe_base + nr_pages * PAGE_SIZE;
> drivers/../coresight-trbe.c: buf->trbe_limit = compute_trbe_buffer_limit(handle);
> drivers/../coresight-trbe.c: buf->trbe_limit -= PAGE_SIZE;
Those are the places where we compute the trbe_limit, *before*
we enable the TRBE. And we don't change recompute the limit
*without disabling* the TRBE. To make it more clear, the
only place where we set TRBE enabled without "computing"
the trbe_limit is when we hit a spurious interrupt.
But the value in the TRBLIMITR should already match the
buf->trbe_limit and we are only going to re-enable the
TRBE with the same limit. The other option is to
pass down the "limit" to the set_trbe_enabled().
>
>> function could simply be :
>>
>> set_trbe_enabled(trbe_buf)
>> {
>> limitr = trbe_buf->limit | LIMITR_ENABLE
>> write(limitr, TRBLIMITR_EL1);
>> ...
>> }
>
> Is the potential for performance improvement here, out weigh possible
> risks of using buf->trbe_limit directly while enabling the TRBE ?
I somehow don't like the fact that we have additional write and read
for the most common case of the TRBE usage (i.e, for arm_trbe_enable()).
If we could avoid that, that may be better.
Cheers
Suzuki
^ permalink raw reply
* Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
From: Russell King (Oracle) @ 2022-01-05 13:53 UTC (permalink / raw)
To: Jon Hunter
Cc: Ard Biesheuvel, Geert Uytterhoeven, Marek Szyprowski, Linux ARM,
Nicolas Pitre, Arnd Bergmann, Kees Cook, Keith Packard,
Linus Walleij, Nick Desaulniers, Tony Lindgren,
Krzysztof Kozlowski, Linux Samsung SOC, Linux-Renesas,
linux-tegra@vger.kernel.org
In-Reply-To: <4ae3e371-68d0-64d7-713e-88af45875b3f@nvidia.com>
On Wed, Jan 05, 2022 at 11:33:48AM +0000, Jon Hunter wrote:
> On 05/01/2022 11:12, Ard Biesheuvel wrote:
> > Thanks for the report.
> >
> > It would be helpful if you could provide some more context:
> > - does it happen on a LPAE build too?
> > - does it only happen on SMP capable systems?
>
> These are all SMP systems.
>
> > - does it reproduce on such systems when using only a single CPU?
> > (i.e., pass 'nosmp' on the kernel command line)
>
> I would need to try this.
Please note that I want an answer on the vmap stack patches by the
end of today (UK time - so about five hours after this email has
been sent) as we have only tonight and tomorrow's linux-next before
the probable opening of the merge window.
The options are:
1. The problem gets fixed today and I merge the fix today so it can
get tested in linux-next over the next few days by the various
build farms and test setups.
2. We postpone the merging of this until the very end of the merge
window to give more time to sort out this mess - but what it
means is keeping it in linux-next and keeping various platforms
broken during that period. However, this is really not fair for
other people, and some would say this isn't even an option.
3. We drop the entire series for this merge window, meaning it gets
dropped from linux-next, and have another go for the neext merge
window.
Sorry for being so demanding, but we're far too close to the merge
window to be trying to debug a feature that is clearly causing a
regression for several platforms.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
From: Thomas Hellström @ 2022-01-05 13:44 UTC (permalink / raw)
To: Zeng, Oak, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Bloomfield, Jon, Vetter, Daniel,
Wilson, Chris P
Cc: Auld, Matthew
In-Reply-To: <b00e0f20-4398-f97d-5343-88f32828c468@linux.intel.com>
On 1/4/22 17:07, Thomas Hellström wrote:
> Hi, Oak,
>
> On 1/4/22 16:35, Zeng, Oak wrote:
>>
>> Regards,
>> Oak
>>
>>> -----Original Message-----
>>> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>> Sent: January 4, 2022 3:29 AM
>>> To: Zeng, Oak <oak.zeng@intel.com>; intel-gfx@lists.freedesktop.org;
>>> dri-devel@lists.freedesktop.org
>>> Cc: Auld, Matthew <matthew.auld@intel.com>
>>> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
>>> resource as argument for gtt binding / unbinding
>>>
>>> Hi, Oak.
>>>
>>> On 1/4/22 00:08, Zeng, Oak wrote:
>>>> Regards,
>>>> Oak
>>> Looks like your emails always start with "Regards, Oak". a
>>> misconfiguration?
>> My mail client (outlook) is set to automatically add a regards, when
>> I compose new mail or reply email. Not a big problem 😊
>>
>>>
>>>>> -----Original Message-----
>>>>> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>>>> Sent: January 3, 2022 1:58 PM
>>>>> To: Zeng, Oak <oak.zeng@intel.com>;
>>>>> intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>>>>> Cc: Auld, Matthew <matthew.auld@intel.com>
>>>>> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
>>>>> resource as argument for gtt binding / unbinding
>>>>>
>>>>> Hi, Oak.
>>>>>
>>>>> On 1/3/22 19:17, Zeng, Oak wrote:
>>>>>> Regards,
>>>>>> Oak
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On
>>>>>>> Behalf Of Thomas Hellström
>>>>>>> Sent: January 3, 2022 7:00 AM
>>>>>>> To: intel-gfx@lists.freedesktop.org;
>>>>>>> dri-devel@lists.freedesktop.org
>>>>>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>; Auld,
>>>>>>> Matthew <matthew.auld@intel.com>
>>>>>>> Subject: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
>>>>>>> resource as argument for gtt binding / unbinding
>>>>>>>
>>>>>>> When introducing asynchronous unbinding, the vma itself may no
>>>>>>> longer
>>>>>>> be alive when the actual binding or unbinding takes place.
>>>>>> Can we take an extra reference counter of the vma to keep the vma
>>>>>> alive, until the actual binding/unbinding takes place?
>>>>> The point here is that that's not needed, and should be avoided.
>>>> Can you explain more why "keeping vma alive until unbinding takes
>>>> place" should be avoided?
>>>>
>>>> As I understand it, your series introduce asynchronized unbinding.
>>>> But since vma might be no longer alive at the time of unbinding.
>>> To overcome this difficulty, you introduce a vma resource structure
>>> and you guarantee vma resource is alive at bind/unbind time. So
>>> you can use vma resource for the bind/unbind operation. My question
>>> is, can we achieve the asynchronized unbinding still using vma
>>> structure by keeping vma structure alive ( by ref count it). This
>>> way the change should be much smaller (compared to this series). Why
>>> it is harmful to keep the vma alive? Maybe you have other reasons to
>>> introduce vma resource that I don't see.
>>>
>>> When we allow asynchronous unbinding, it's allowed to immediately
>>> rebind
>>> the vma, possibly into the same gpu virtual address, but with different
>>> pages. And when doing that we don't want to block waiting for the
>>> unbind
>>> to execute.
>> Imagine this sequence:
>>
>> 1. Virtual address a1 is bound to physical page p1
>> 2. Unbind a1 from p1, asynchronous so actual unbind not happen yet
>> 3. bind a1 to physical page p2, page table is changed, now a1
>> pointing to p2 in page table.
>> 4. #2 now take place now - since in page table, a1 points to p2 now,
>> does a1 point to scratch page after #4?
>
> Here, 3) will also become async, awaiting any pending unbinds in the
> address range provided to 3), in particular, the bind in 3) will await
> 4). See i915_vma_resource_bind_dep_await(), and the discussion on
> whether or not to use an interval tree for this at the start of
> i915_vma_resource.c
>
>> In fact, we could allow a large number of outstanding binds
>>> and unbinds for a vma, which makes the vma structure unsuitable to
>>> track
>>> this, since there will no longer be a single mapping between a set of
>>> active pages and a vma, or a virtual gpu range and a vma.
>> I agree that if pages - vma - virtual gpu range is not 1:1:1 mapping,
>> we need introduce a finer-grained vma resource to for the non-1:1
>> mapping. I also understand the asynchronous unbinding utilize the
>> virtual address space more effectively. But my feeling is that this
>> non-1:1 mapping makes our program hard to understand and maintain.
>> Since this non- 1:1 mapping is introduced by asynchronous
>> binding/unbinding, maybe the real question here is, is it really
>> benefit to introduce asynchronous unbinding?
>
> That's a relevant question, which I've asked myself a couple of times.
> Async unbinding has complicated things like error capture and indeed
> complicates the understanding of the binding process as well.
>
> The main gain is that we avoid a sync point at LMEM eviction, enabling
> us to pipeline eviction, moving forward it may also find use in the
> shrinker and for user-space prematurely wanting to re-use softpin
> addresses.
>
> /Thomas
>
>>
>> I am still not familiar enough to the codes. I suggest other experts
>> to take a look also. @Bloomfield, Jon @Vetter, Daniel @Wilson, Chris P.
It might make sense here to point out as well that the direction from
the arch team is towards moving towards gpu-writes of page-table entries
for binding and unbinding, also keeping small PCI bars in mind, which
will more or less force us to allow async unbinding for maintained
performance.
/Thomas
>>
>> Regards,
>> Oak
>>> Thanks,
>>>
>>> /Thomas
>>>
>>>> Regards,
>>>> Oak
>>>>
>>>> If the
>>>>> vma is no longer alive, that means nobody uses it anymore, but the
>>>>> GPU
>>>>> may still have work in the pipe that references the GPU virtual
>>>>> address.
>>>>>
>>>>> /Thomas.
>>>>>
^ permalink raw reply
* Re: [PATCH 3/4] coresight: trbe: Work around the invalid prohibited states
From: Suzuki K Poulose @ 2022-01-05 13:54 UTC (permalink / raw)
To: Anshuman Khandual, linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Mathieu Poirier, coresight,
linux-doc, linux-kernel
In-Reply-To: <68961242-3d9b-a26d-3a0f-0d2ace04a17b@arm.com>
On 05/01/2022 11:16, Anshuman Khandual wrote:
>
>
> On 1/5/22 3:43 PM, Suzuki K Poulose wrote:
>> Hi Anshuman
>>
>> On 05/01/2022 05:05, Anshuman Khandual wrote:
>>> TRBE implementations affected by Arm erratum #2038923 might get TRBE into
>>> an inconsistent view on whether trace is prohibited within the CPU. As a
>>> result, the trace buffer or trace buffer state might be corrupted. This
>>> happens after TRBE buffer has been enabled by setting TRBLIMITR_EL1.E,
>>> followed by just a single context synchronization event before execution
>>> changes from a context, in which trace is prohibited to one where it isn't,
>>> or vice versa. In these mentioned conditions, the view of whether trace is
>>> prohibited is inconsistent between parts of the CPU, and the trace buffer
>>> or the trace buffer state might be corrupted.
>>>
>>> Work around this problem in the TRBE driver by preventing an inconsistent
>>> view of whether the trace is prohibited or not based on TRBLIMITR_EL1.E by
>>> immediately following a change to TRBLIMITR_EL1.E with at least one ISB
>>> instruction before an ERET, or two ISB instructions if no ERET is to take
>>> place. This adds a new cpu errata in arm64 errata framework and also
>>> updates TRBE driver as required.
>>>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Will Deacon <will@kernel.org>
>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
>>> Cc: coresight@lists.linaro.org
>>> Cc: linux-doc@vger.kernel.org
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>> ---
>>> Documentation/arm64/silicon-errata.rst | 2 +
>>> arch/arm64/Kconfig | 23 ++++++++++
>>> arch/arm64/kernel/cpu_errata.c | 9 ++++
>>> arch/arm64/tools/cpucaps | 1 +
>>> drivers/hwtracing/coresight/coresight-trbe.c | 47 +++++++++++++++-----
>>> 5 files changed, 72 insertions(+), 10 deletions(-)
>>
>> As with the previous patch, it may be a good idea to split the
>> patch to arm64 and trbe parts.
>
> Sure, will do.
>
>>
>>>
>>> diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
>>> index c9b30e6c2b6c..e0ef3e9a4b8b 100644
>>> --- a/Documentation/arm64/silicon-errata.rst
>>> +++ b/Documentation/arm64/silicon-errata.rst
>>> @@ -54,6 +54,8 @@ stable kernels.
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> | ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> +| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
>>> ++----------------+-----------------+-----------------+-----------------------------+
>>> | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 2105b68d88db..026e34fb6fad 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -796,6 +796,29 @@ config ARM64_ERRATUM_2064142
>>> If unsure, say Y.
>>> +config ARM64_ERRATUM_2038923
>>> + bool "Cortex-A510: 2038923: workaround TRBE corruption with enable"
>>> + depends on CORESIGHT_TRBE
>>> + default y
>>> + help
>>> + This option adds the workaround for ARM Cortex-A510 erratum 2038923.
>>> +
>>> + Affected Cortex-A510 core might cause an inconsistent view on whether trace is
>>> + prohibited within the CPU. As a result, the trace buffer or trace buffer state
>>> + might be corrupted. This happens after TRBE buffer has been enabled by setting
>>> + TRBLIMITR_EL1.E, followed by just a single context synchronization event before
>>> + execution changes from a context, in which trace is prohibited to one where it
>>> + isn't, or vice versa. In these mentioned conditions, the view of whether trace
>>> + is prohibited is inconsistent between parts of the CPU, and the trace buffer or
>>> + the trace buffer state might be corrupted.
>>> +
>>> + Work around this in the driver by preventing an inconsistent view of whether the
>>> + trace is prohibited or not based on TRBLIMITR_EL1.E by immediately following a
>>> + change to TRBLIMITR_EL1.E with at least one ISB instruction before an ERET, or
>>> + two ISB instructions if no ERET is to take place.
>>> +
>>> + If unsure, say Y.
>>> +
>>> config CAVIUM_ERRATUM_22375
>>> bool "Cavium erratum 22375, 24313"
>>> default y
>>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>>> index cbb7d5a9aee7..60b0c1f1d912 100644
>>> --- a/arch/arm64/kernel/cpu_errata.c
>>> +++ b/arch/arm64/kernel/cpu_errata.c
>>> @@ -607,6 +607,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>>> ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A510, 0, 0, 2)
>>> },
>>> #endif
>>> +#ifdef CONFIG_ARM64_ERRATUM_2038923
>>> + {
>>> + .desc = "ARM erratum 2038923",
>>> + .capability = ARM64_WORKAROUND_2038923,
>>> +
>>> + /* Cortex-A510 r0p0 - r0p2 */
>>> + ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A510, 0, 0, 2)
>>> + },
>>> +#endif
>>> {
>>> }
>>> };
>>> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
>>> index fca3cb329e1d..45a06d36d080 100644
>>> --- a/arch/arm64/tools/cpucaps
>>> +++ b/arch/arm64/tools/cpucaps
>>> @@ -56,6 +56,7 @@ WORKAROUND_1463225
>>> WORKAROUND_1508412
>>> WORKAROUND_1542419
>>> WORKAROUND_2064142
>>> +WORKAROUND_2038923
>>> WORKAROUND_TRBE_OVERWRITE_FILL_MODE
>>> WORKAROUND_TSB_FLUSH_FAILURE
>>> WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
>>> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
>>> index ec24b62b2cec..0689c6dab96d 100644
>>> --- a/drivers/hwtracing/coresight/coresight-trbe.c
>>> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
>>> @@ -92,11 +92,13 @@ struct trbe_buf {
>>> #define TRBE_WORKAROUND_OVERWRITE_FILL_MODE 0
>>> #define TRBE_WORKAROUND_WRITE_OUT_OF_RANGE 1
>>> #define TRBE_WORKAROUND_SYSREG_WRITE_FAILURE 2
>>> +#define TRBE_WORKAROUND_CORRUPTION_WITH_ENABLE 3
>>> static int trbe_errata_cpucaps[] = {
>>> [TRBE_WORKAROUND_OVERWRITE_FILL_MODE] = ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE,
>>> [TRBE_WORKAROUND_WRITE_OUT_OF_RANGE] = ARM64_WORKAROUND_TRBE_WRITE_OUT_OF_RANGE,
>>> [TRBE_WORKAROUND_SYSREG_WRITE_FAILURE] = ARM64_WORKAROUND_2064142,
>>> + [TRBE_WORKAROUND_CORRUPTION_WITH_ENABLE] = ARM64_WORKAROUND_2038923,
>>> -1, /* Sentinel, must be the last entry */
>>> };
>>> @@ -174,6 +176,11 @@ static inline bool trbe_may_fail_sysreg_write(struct trbe_cpudata *cpudata)
>>> return trbe_has_erratum(cpudata, TRBE_WORKAROUND_SYSREG_WRITE_FAILURE);
>>> }
>>> +static inline bool trbe_may_corrupt_with_enable(struct trbe_cpudata *cpudata)
>>> +{
>>
>> minor nit: trbe_needs_{ctxt_sync, isb}_after_enable() ?
>
> trbe_needs_ctxt_sync_after_enable() sounds better. Also will have to change
> the index above as well .. TRBE_NEEDS_CTXT_SYNC_AFTER_ENABLE.
>
>>
>>> + return trbe_has_erratum(cpudata, TRBE_WORKAROUND_CORRUPTION_WITH_ENABLE);
>>> +}
>>> +
>>> static int trbe_alloc_node(struct perf_event *event)
>>> {
>>> if (event->cpu == -1)
>>> @@ -187,6 +194,30 @@ static inline void trbe_drain_buffer(void)
>>> dsb(nsh);
>>> }
>>> +static inline void set_trbe_enabled(struct trbe_cpudata *cpudata)
>>> +{
>>> + u64 trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
>>
>> minor nit: This implies we do the TRBE programming in the following
>> manner in the common case (i.e, TRBE enabled in the beginning of a
>> session).
>> -> set TRBE LIMIT
>> -> read TRBE LIMIT
>> -> set TRBE ENABLED
>>
>> Could we please optimize this ? I believe the buf->trbe_limit
>> must hold the LIMITR value at any point in time. And thus this
>
> But is not bit risky though ! We have got the following places where
> given trbe_limit instance changes its value.
>
> drivers/../coresight-trbe.c: buf->trbe_limit = buf->trbe_base + nr_pages * PAGE_SIZE;
> drivers/../coresight-trbe.c: buf->trbe_limit = compute_trbe_buffer_limit(handle);
> drivers/../coresight-trbe.c: buf->trbe_limit -= PAGE_SIZE;
Those are the places where we compute the trbe_limit, *before*
we enable the TRBE. And we don't change recompute the limit
*without disabling* the TRBE. To make it more clear, the
only place where we set TRBE enabled without "computing"
the trbe_limit is when we hit a spurious interrupt.
But the value in the TRBLIMITR should already match the
buf->trbe_limit and we are only going to re-enable the
TRBE with the same limit. The other option is to
pass down the "limit" to the set_trbe_enabled().
>
>> function could simply be :
>>
>> set_trbe_enabled(trbe_buf)
>> {
>> limitr = trbe_buf->limit | LIMITR_ENABLE
>> write(limitr, TRBLIMITR_EL1);
>> ...
>> }
>
> Is the potential for performance improvement here, out weigh possible
> risks of using buf->trbe_limit directly while enabling the TRBE ?
I somehow don't like the fact that we have additional write and read
for the most common case of the TRBE usage (i.e, for arm_trbe_enable()).
If we could avoid that, that may be better.
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iomap: Address soft lockup in iomap_finish_ioend()
From: Brian Foster @ 2022-01-05 13:56 UTC (permalink / raw)
To: Dave Chinner
Cc: Darrick J. Wong, hch@infradead.org, Matthew Wilcox,
Trond Myklebust, linux-fsdevel@vger.kernel.org,
trondmy@kernel.org, axboe@kernel.dk, linux-xfs@vger.kernel.org
In-Reply-To: <20220105021022.GL945095@dread.disaster.area>
On Wed, Jan 05, 2022 at 01:10:22PM +1100, Dave Chinner wrote:
> On Tue, Jan 04, 2022 at 03:12:30PM -0800, Darrick J. Wong wrote:
> > On Wed, Jan 05, 2022 at 08:52:27AM +1100, Dave Chinner wrote:
> > > On Tue, Jan 04, 2022 at 11:22:27AM -0800, Darrick J. Wong wrote:
> > > > On Tue, Jan 04, 2022 at 10:14:27AM -0800, hch@infradead.org wrote:
> > > > > On Tue, Jan 04, 2022 at 06:08:24PM +0000, Matthew Wilcox wrote:
> > > > > > I think it's fine to put in a fix like this now that's readily
> > > > > > backportable. For folios, I can't help but think we want a
> > > > > > restructuring to iterate per-extent first, then per-folio and finally
> > > > > > per-sector instead of the current model where we iterate per folio,
> > > > > > looking up the extent for each sector.
> > > > >
> > > > > We don't look up the extent for each sector. We look up the extent
> > > > > once and then add as much of it as we can to the bio until either the
> > > > > bio is full or the extent ends. In the first case we then allocate
> > > > > a new bio and add it to the ioend.
> > > >
> > > > Can we track the number of folios that have been bio_add_folio'd to the
> > > > iomap_ioend, and make iomap_can_add_to_ioend return false when the
> > > > number of folios reaches some threshold? I think that would solve the
> > > > problem of overly large ioends while not splitting folios across ioends
> > > > unnecessarily.
> > >
> > > See my reply to Christoph up thread.
> > >
> > > The problem is multiple blocks per page/folio - bio_add_folio() will
> > > get called for the same folio many times, and we end up not knowing
> > > when a new page/folio is attached. Hence dynamically calculating it
> > > as we build the bios is .... convoluted.
> >
> > Hm. Indulge me in a little more frame-shifting for a moment --
> >
> > As I see it, the problem here is that we're spending too much time
> > calling iomap_finish_page_writeback over and over and over, right?
> >
I think the fundamental problem is an excessively large page list that
requires a tight enough loop in iomap_finish_ioend() with no opportunity
for scheduling. AIUI, this can occur a few different ways atm. The first
is a large bio chain associated with an ioend. Another potential vector
is a series of large bio vecs, since IIUC a vector can cover something
like 4GB worth of pages if physically contiguous. Since Trond's instance
seems to be via the completion workqueue, yet another vector is likely
via a chain of merged ioends.
IOW, I think there is potential for such a warning in either of the two
loops in iomap_finish_ioend() or the ioend loop in iomap_finish_ioends()
depending on circumstance. Trond's earlier feedback on his initial patch
(i.e. without ioend size capping) suggests he's hitting more of the bio
chain case, since a cond_resched() in the bio iteration loop in
iomap_finish_ioend() mitigated the problem but lifting it outside into
iomap_finish_ioends() did not.
> > If we have a single page with a single mapping that fits in a single
> > bio, that means we call bio_add_page once, and on the other end we call
> > iomap_finish_page_writeback once.
> >
> > If we have (say) an 8-page folio with 4 blocks per page, in the worst
> > case we'd create 32 different ioends, each with a single-block bio,
> > which means 32 calls to iomap_finish_page_writeback, right?
>
> Yes, but in this case, we've had to issue and complete 32 bios and
> ioends to get one call to end_page_writeback(). That is overhead we
> cannot avoid if we have worst-case physical fragmentation of the
> filesystem. But, quite frankly, if that's the case we just don't
> care about performance of IO completion - performance will suck
> because we're doing 32 IOs instead of 1 for that data, not because
> IO completion has to do more work per page/folio....
>
> > From what I can see, the number of bio_add_folio calls is proportional
> > to the amount of ioend work we do without providing any external signs
> > of life to the watchdog, right?
> >
> > So forget the number of folios or the byte count involved. Isn't the
> > number of future iomap_finish_page_writeback calls exactly the metric
> > that we want to decide when to cut off ioend submission?
>
> Isn't that exactly what I suggested by counting bio segments in the
> ioend at bio submission time? I mean, iomap_finish_page_writeback()
> iterates bio segments, not pages, folios or filesystem blocks....
>
> > > Hence generic iomap code will only end up calling
> > > iomap_finish_ioends() with the same ioend that was submitted. i.e.
> > > capped to 4096 pages by this patch. THerefore it does not need
> > > cond_resched() calls - the place that needs it is where the ioends
> > > are merged and then finished. That is, in the filesystem completion
> > > processing that does the merging....
> >
> > Huh? I propose adding cond_resched to iomap_finish_ioends (plural),
>
> Which is only called from XFS on merged ioends after XFS has
> processed the merged ioend.....
>
> > which walks a list of ioends and calls iomap_finish_ioend (singular) on
> > each ioend. IOWs, we'd call cond_resched in between finishing one ioend
> > and starting on the next one. Isn't that where ioends are finished?
> >
> > (I'm starting to wonder if we're talking past each other?)
> >
> > So looking at xfs_end_io:
> >
> > /* Finish all pending io completions. */
> > void
> > xfs_end_io(
> > struct work_struct *work)
> > {
> > struct xfs_inode *ip =
> > container_of(work, struct xfs_inode, i_ioend_work);
> > struct iomap_ioend *ioend;
> > struct list_head tmp;
> > unsigned long flags;
> >
> > spin_lock_irqsave(&ip->i_ioend_lock, flags);
> > list_replace_init(&ip->i_ioend_list, &tmp);
> > spin_unlock_irqrestore(&ip->i_ioend_lock, flags);
> >
> > iomap_sort_ioends(&tmp);
> > while ((ioend = list_first_entry_or_null(&tmp, struct iomap_ioend,
> > io_list))) {
> > list_del_init(&ioend->io_list);
> >
> > Here we pull the first ioend off the sorted list of ioends.
> >
> > iomap_ioend_try_merge(ioend, &tmp);
> >
> > Now we've merged that first ioend with as many subsequent ioends as we
> > could merge. Let's say there were 200 ioends, each 100MB. Now ioend
>
> Ok, so how do we get to this completion state right now?
>
> 1. an ioend is a physically contiguous extent so submission is
> broken down into an ioend per physical extent.
> 2. we merge logically contiguous ioends at completion.
>
> So, if we have 200 ioends of 100MB each that are logically
> contiguous we'll currently always merge them into a single 20GB
> ioend that gets processed as a single entity even if submission
> broke them up because they were physically discontiguous.
>
> Now, with this patch we add:
>
> 3. Individual ioends are limited to 16MB.
> 4. completion can only merge physically contiguous ioends.
> 5. we cond_resched() between physically contiguous ioend completion.
>
> Submission will break that logically contiguous 20GB dirty range
> down into 200x6x16MB ioends.
>
> Now completion will only merge ioends that are both physically and
> logically contiguous. That results in a maximum merged ioend chain
> size of 100MB at completion. They'll get merged one 100MB chunk at a
> time.
>
I'm missing something with the reasoning here.. how does a contiguity
check in the ioend merge code guarantee we don't construct an
excessively large list of pages via a chain of merged ioends? Obviously
it filters out the discontig case, but what if the extents are
physically contiguous?
> > is a chain (of those other 199 ioends) representing 20GB of data.
> >
> > xfs_end_ioend(ioend);
>
> We now do one conversion transaction for the entire 100MB extent,
> then....
>
> > At the end of this routine, we call iomap_finish_ioends on the 20GB
> > ioend chain. This now has to mark 5.2 million pages...
>
> run iomap_finish_ioends() on 100MB of pages, which is about 25,000
> pages, not 5 million...
>
> > cond_resched();
> >
> > ...before we get to the cond_resched.
>
> ... and so in this scenario this patch reduces the time between
> reschedule events by a factor of 200 - the number of physical
> extents the ioends map....
>
> That's kind of my point - we can't ignore why the filesystem needs
> merging or how it should optimise merging for it's own purposes in
> this discussion. Because logically merged ioends require the
> filesystem to do internal loops over physical discontiguities,
> requiring us to drive cond_resched() into both the iomap loops and
> the lower layer filesystem loops.
>
> i.e. when we have ioend merging based on logical contiguity, we need
> to limit the number of the loops the filesystem does internally, not
> just the loops that the ioend code is doing...
>
> > I'd really rather do the
> > cond_resched between each of those 200 ioends that (supposedly) are
> > small enough not to trip the hangcheck timers.
> >
> > }
> > }
> > /*
> > * Mark writeback finished on a chain of ioends. Caller must not call
> > * this function from atomic/softirq context.
> > */
> > void
> > iomap_finish_ioends(struct iomap_ioend *ioend, int error)
> > {
> > struct list_head tmp;
> >
> > list_replace_init(&ioend->io_list, &tmp);
> > iomap_finish_ioend(ioend, error);
> >
> > while (!list_empty(&tmp)) {
> > cond_resched();
> >
> > So I propose doing it ^^^ here instead.
> >
> > ioend = list_first_entry(&tmp, struct iomap_ioend, io_list);
> > list_del_init(&ioend->io_list);
> > iomap_finish_ioend(ioend, error);
> > }
> > }
Hmm.. I'm not seeing how this is much different from Dave's patch, and
I'm not totally convinced the cond_resched() in Dave's patch is
effective without something like Darrick's earlier suggestion to limit
the $object (page/folio/whatever) count of the entire merged mapping (to
ensure that iomap_finish_ioend() is no longer a soft lockup vector by
itself).
Trond reports that the test patch mitigates his reproducer, but that
patch also includes the ioend size cap and so the test doesn't
necessarily isolate whether the cond_resched() is effective or whether
the additional submission/completion overhead is enough to avoid the
pathological conditions that enable it via the XFS merging code. I'd be
curious to have a more tangible datapoint on that. The easiest way to
test without getting into the weeds of looking at merging behavior is
probably just see whether the problem returns with the cond_resched()
removed and all of the other changes in place. Trond, is that something
you can test?
Brian
>
> Yes, but this only addresses a single aspect of the issue when
> filesystem driven merging is used. That is, we might have just had
> to do a long unbroken loop in xfs_end_ioend() that might have to run
> conversion of several thousand physical extents that the logically
> merged ioends might have covered. Hence even with the above, we'd
> still need to add cond_resched() calls to the XFS code. Hence from
> an XFS IO completion point of view, we only want to merge to
> physical extent boundaries and issue cond_resched() at physical
> extent boundaries because that's what our filesystem completion
> processing loops on, not pages/folios.
>
> Hence my point that we cannot ignore what the filesystem is doing
> with these merged ioends and only think about iomap in isolation.
>
> Cheers,
>
> Dave.
>
> --
> Dave Chinner
> david@fromorbit.com
>
^ permalink raw reply
* [PATCH v2 0/3] x86/perfc: assorted adjustments
From: Jan Beulich @ 2022-01-05 13:56 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper, Wei Liu, Roger Pau Monné
Addressing some observations made while reviewing other patches.
1: VMX: sync VM-exit perf counters with known VM-exit reasons
2: SVM: sync VM-exit perf counters with known VM-exit reasons
3: x86/perfc: fold HVM's VM-exit counter arrays
Jan
^ permalink raw reply
* [PATCH v1 05/34] ci: explicitly skip I/O tests on alpine
From: Alex Bennée @ 2022-01-05 13:49 UTC (permalink / raw)
To: qemu-devel
Cc: fam, Thomas Huth, berrange, Beraldo Leal, Alex Bennée, f4bug,
Wainer dos Santos Moschetta, stefanha, crosa, pbonzini,
Philippe Mathieu-Daudé, aurelien
In-Reply-To: <20220105135009.1584676-1-alex.bennee@linaro.org>
From: Daniel P. Berrangé <berrange@redhat.com>
The block I/O tests don't work on Alpine because their alternative libc
impl emits different strings for errnos, which breaks the expected
output matching. e.g.
=== IO: pattern 102
wrote 512/512 bytes at offset 512
512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-qemu-img: Error while reading offset 0 of blkdebug:TEST_DIR/blkdebug.conf:TEST_DIR/t.IMGFMT: Input/output error
+qemu-img: Error while reading offset 0 of blkdebug:TEST_DIR/blkdebug.conf:TEST_DIR/t.IMGFMT: I/O error
4
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
Formatting 'TEST_DIR/t.IMGFMT.2', fmt=IMGFMT size=0
Currently the I/O tests are skipped as a side effect of the Alpine image
containing a minimal busybox 'sed' binary, rather than GNU sed. This is
a fragile assumption that will be invalidated when the dockerfile is
changed to be autogenerated from a standardized package list that
includes GNU sed.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20211215141949.3512719-6-berrange@redhat.com>
---
.gitlab-ci.d/buildtest.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index 7e1cb0b3c2..e77aec873e 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -24,7 +24,7 @@ check-system-alpine:
artifacts: true
variables:
IMAGE: alpine
- MAKE_CHECK_ARGS: check
+ MAKE_CHECK_ARGS: check-unit check-qtest
avocado-system-alpine:
extends: .avocado_test_job_template
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v3 net-next 2/2] bpf: selftests: add bind retry for post_bind{4, 6}
From: Eric Dumazet @ 2022-01-05 13:57 UTC (permalink / raw)
To: Menglong Dong
Cc: Jakub Kicinski, Daniel Borkmann, David Miller, Hideaki YOSHIFUJI,
David Ahern, Shuah Khan, Alexei Starovoitov, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, netdev, LKML, open list:KERNEL SELFTEST FRAMEWORK, bpf,
Menglong Dong
In-Reply-To: <20220105131849.2559506-3-imagedong@tencent.com>
On Wed, Jan 5, 2022 at 5:21 AM <menglong8.dong@gmail.com> wrote:
>
> From: Menglong Dong <imagedong@tencent.com>
>
> With previous patch, kernel is able to 'put_port' after sys_bind()
> fails. Add the test for that case: rebind another port after
> sys_bind() fails. If the bind success, it means previous bind
> operation is already undoed.
>
> Signed-off-by: Menglong Dong <imagedong@tencent.com>
> ---
> tools/testing/selftests/bpf/test_sock.c | 166 +++++++++++++++++++++---
> 1 file changed, 146 insertions(+), 20 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/test_sock.c b/tools/testing/selftests/bpf/test_sock.c
> index e8edd3dd3ec2..68525d68d4e5 100644
> --- a/tools/testing/selftests/bpf/test_sock.c
> +++ b/tools/testing/selftests/bpf/test_sock.c
> @@ -35,12 +35,15 @@ struct sock_test {
> /* Endpoint to bind() to */
> const char *ip;
> unsigned short port;
> + unsigned short port_retry;
> /* Expected test result */
> enum {
> LOAD_REJECT,
> ATTACH_REJECT,
> BIND_REJECT,
> SUCCESS,
> + RETRY_SUCCESS,
> + RETRY_REJECT
> } result;
> };
>
> @@ -60,6 +63,7 @@ static struct sock_test tests[] = {
> 0,
> NULL,
> 0,
> + 0,
> LOAD_REJECT,
> },
I assume we tried C99 initializers here, and this failed for some reason ?
diff --git a/tools/testing/selftests/bpf/test_sock.c
b/tools/testing/selftests/bpf/test_sock.c
index e8edd3dd3ec2..b57ce9f3eabf 100644
--- a/tools/testing/selftests/bpf/test_sock.c
+++ b/tools/testing/selftests/bpf/test_sock.c
@@ -54,13 +54,13 @@ static struct sock_test tests[] = {
BPF_MOV64_IMM(BPF_REG_0, 1),
BPF_EXIT_INSN(),
},
- BPF_CGROUP_INET4_POST_BIND,
- BPF_CGROUP_INET4_POST_BIND,
- 0,
- 0,
- NULL,
- 0,
- LOAD_REJECT,
+ .expected_attach_type = BPF_CGROUP_INET4_POST_BIND,
+ .attach_type = BPF_CGROUP_INET4_POST_BIND,
+ .domain = 0,
+ .type = 0,
+ .ip = NULL,
+ .port = 0,
+ .result = LOAD_REJECT,
},
{
"bind4 load with invalid access: mark",
^ permalink raw reply related
* [PATCH v2 1/3] VMX: sync VM-exit perf counters with known VM-exit reasons
From: Jan Beulich @ 2022-01-05 13:57 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper, Wei Liu, Roger Pau Monné, Kevin Tian,
Jun Nakajima
In-Reply-To: <ff461a77-93a0-5424-6565-2e947bec3912@suse.com>
This has gone out of sync over time. Introduce a simplistic mechanism to
hopefully keep things in sync going forward.
Also limit the array index to just the "basic exit reason" part, which is
what the pseudo-enumeration covers.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Use sentinel comment only.
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3869,7 +3869,7 @@ void vmx_vmexit_handler(struct cpu_user_
else
HVMTRACE_ND(VMEXIT, 0, 1/*cycles*/, exit_reason, regs->eip);
- perfc_incra(vmexits, exit_reason);
+ perfc_incra(vmexits, (uint16_t)exit_reason);
/* Handle the interrupt we missed before allowing any more in. */
switch ( (uint16_t)exit_reason )
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -219,6 +219,7 @@ static inline void pi_clear_sn(struct pi
#define EXIT_REASON_PML_FULL 62
#define EXIT_REASON_XSAVES 63
#define EXIT_REASON_XRSTORS 64
+/* Remember to also update VMX_PERF_EXIT_REASON_SIZE! */
/*
* Interruption-information format
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions,
#ifdef CONFIG_HVM
-#define VMX_PERF_EXIT_REASON_SIZE 56
+#define VMX_PERF_EXIT_REASON_SIZE 65
#define VMX_PERF_VECTOR_SIZE 0x20
PERFCOUNTER_ARRAY(vmexits, "vmexits", VMX_PERF_EXIT_REASON_SIZE)
PERFCOUNTER_ARRAY(cause_vector, "cause vector", VMX_PERF_VECTOR_SIZE)
^ permalink raw reply
* Re: [PATCH v2 1/3] sched/pelt: Don't sync hardly util_sum with uti_avg
From: Vincent Guittot @ 2022-01-05 13:57 UTC (permalink / raw)
To: Dietmar Eggemann
Cc: mingo, peterz, juri.lelli, rostedt, bsegall, mgorman, bristot,
linux-kernel, rickyiu, odin, sachinp, naresh.kamboju
In-Reply-To: <8f39d837-2589-4f7b-5232-1ed134fb1ad7@arm.com>
On Wed, 5 Jan 2022 at 14:15, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
>
> On 04/01/2022 14:42, Vincent Guittot wrote:
> > On Tue, 4 Jan 2022 at 12:47, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
> >>
> >> On 22/12/2021 10:38, Vincent Guittot wrote:
>
> [...]
>
> >> I still wonder whether the regression only comes from the changes in
> >> update_cfs_rq_load_avg(), introduced by 1c35b07e6d39.
> >> And could be fixed only by this part of the patch-set (A):
> >
> > I have been able to trigger the warning even with (A) though It took
> > much more time.
> > And I have been able to catch wrong situations (with additional
> > traces) in the 3 places A, B and C
>
> OK. By wrong situation you mean '_sum < _avg * MIN_DIVIDER' ?
not only.
also util_sum == 0 but util_avg !=0 in different places although these
situation didn't trigger sched_warn because some other sync happened
before the periodic call of __update_blocked_fair
or if nr_running == 1 and and task's util_avg/sum > cfs' util_avg/sum
just before removing the task
>
> >> @@ -3677,15 +3706,22 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq
> >> *cfs_rq)
> >>
> >> r = removed_load;
> >> sub_positive(&sa->load_avg, r);
> >> - sa->load_sum = sa->load_avg * divider;
> >> + sub_positive(&sa->load_sum, r * divider);
> >> + sa->load_sum = max_t(u32, sa->load_sum, sa->load_avg * MIN_DIVIDER);
> >>
> >> r = removed_util;
> >> sub_positive(&sa->util_avg, r);
> >> - sa->util_sum = sa->util_avg * divider;
> >> + sub_positive(&sa->util_sum, r * divider);
> >> + sa->util_sum = max_t(u32, sa->util_sum, sa->util_avg * MIN_DIVIDER);
> >>
> >> r = removed_runnable;
> >> sub_positive(&sa->runnable_avg, r);
> >> - sa->runnable_sum = sa->runnable_avg * divider;
> >> + sub_positive(&sa->runnable_sum, r * divider);
> >> + sa->runnable_sum = max_t(u32, sa->runnable_sum,
> >> + sa->runnable_avg * MIN_DIVIDER);
> >>
> >> i.e. w/o changing update_tg_cfs_X() (and
> >> detach_entity_load_avg()/dequeue_load_avg()).
> >>
> >> update_load_avg()
> >> update_cfs_rq_load_avg() <---
> >> propagate_entity_load_avg()
> >> update_tg_cfs_X() <---
> >>
> >>
> >> I didn't see the SCHED_WARN_ON() [cfs_rq_is_decayed()] when looping on
> >> hackbench in several different sched group levels on
> >> [Hikey620 (Arm64, 8 CPUs, SMP, 4 taskgroups: A/B C/D E/F G/H), >12h uptime].
> >
> > IIRC, it was with hikey960 with cgroup v1
> > As a side note, I never trigger the problem with dragonboard845 and cgroup v2
>
> OK, just started a test on hikey960 cgroupv1. Let's see if I can catch it.
>
> [...]
>
> >>> @@ -3780,7 +3799,11 @@ static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *s
> >>>
> >>> dequeue_load_avg(cfs_rq, se);
> >>> sub_positive(&cfs_rq->avg.util_avg, se->avg.util_avg);
> >>> - cfs_rq->avg.util_sum = cfs_rq->avg.util_avg * divider;
> >>> + sub_positive(&cfs_rq->avg.util_sum, se->avg.util_sum);
> >>> + /* See update_tg_cfs_util() */
> >>> + cfs_rq->avg.util_sum = max_t(u32, cfs_rq->avg.util_sum,
> >>> + cfs_rq->avg.util_avg * MIN_DIVIDER);
> >>> +
> >>
> >> Maybe add a:
> >>
> >> Fixes: fcf6631f3736 ("sched/pelt: Ensure that *_sum is always synced
> >> with *_avg")
> >
> > I spent time thinking about adding fixes tag. There is no crash/warn
> > so far so should we propagate it back in LTS for better performance ?
>
> Not sure I understand. What do you mean by 'should we propagate it back
> in LTS'?
Sorry I had any stables in mind and not only LTS.
Some of the changes done in PELT signal propagation that replace
subtracting util_sum by using util_avg * divider instead, are related
to other problems with sched group hierarchy and
throttling/unthrottling. I'm not 100% confident that using fixes tag
to backport this on stables doesn't need to backport more patches on
other areas in order to not resurrect old problems. So I wonder if
it's worth backporting this on stables
>
> [...]
>
> >> This max_t() should make sure that `_sum is always >= _avg *
> >> MIN_DIVIDER`. Which is not the case sometimes. Currently this is done in
> >>
> >> (1) update_cfs_rq_load_avg()
> >> (2) detach_entity_load_avg() and dequeue_load_avg()
> >> (3) update_tg_cfs_X()
> >>
> >> but not in attach_entity_load_avg(), enqueue_load_avg(). What's the
> >> reason for this?
> >
> > Main reason is that I have never seen the problem.
> > Then, the problem comes from subtracting task's value whereas here we
> > always add positive value
>
> OK, I see. The add_positive()'s in update_tg_cfs_X() deal w/ `long` values.
^ permalink raw reply
* [PATCH v1 06/34] tests/docker: switch fedora image to release 35
From: Alex Bennée @ 2022-01-05 13:49 UTC (permalink / raw)
To: qemu-devel
Cc: fam, Thomas Huth, berrange, Beraldo Leal, Alex Bennée, f4bug,
Wainer dos Santos Moschetta, stefanha, crosa, pbonzini,
Philippe Mathieu-Daudé, aurelien
In-Reply-To: <20220105135009.1584676-1-alex.bennee@linaro.org>
From: Daniel P. Berrangé <berrange@redhat.com>
The Fedora 33 release is shortly end of life. Switch to the newest
Fedora 35 to maximise lifespan until we need to update again.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20211215141949.3512719-7-berrange@redhat.com>
---
tests/docker/dockerfiles/fedora.docker | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/docker/dockerfiles/fedora.docker b/tests/docker/dockerfiles/fedora.docker
index c6fd7e1113..855aefaac5 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -1,4 +1,4 @@
-FROM registry.fedoraproject.org/fedora:33
+FROM registry.fedoraproject.org/fedora:35
# Please keep this list sorted alphabetically
ENV PACKAGES \
--
2.30.2
^ permalink raw reply related
* [PATCH v1 00/34] testing/next and other misc fixes
From: Alex Bennée @ 2022-01-05 13:49 UTC (permalink / raw)
To: qemu-devel
Cc: fam, berrange, f4bug, stefanha, crosa, pbonzini, Alex Bennée,
aurelien
Hi,
Happy New Year QEMU developers. To get our new year off to a quick
start here are a bunch of testing and testing adjacent updates. There
are some miscellaneous updates touching linux-user, ARM virt, and
various other minor code tweaks and cleanups. If maintainers want to
take via their own trees then please grab them otherwise I'm happy to
include them in my next pull request.
Everything is pretty well reviewed except:
- tests/avocado: add :avocado: tags for some tests
- linux-user/elfload: add extra logging for hole finding
- hw/arm: add control knob to disable kaslr_seed via DTB (2 acks, 1 sobs)
Alex Bennée (7):
hw/arm: add control knob to disable kaslr_seed via DTB
monitor: move x-query-profile into accel/tcg to fix build
docs/devel: update C standard to C11
docs/devel: more documentation on the use of suffixes
linux-user/elfload: add extra logging for hole finding
linux-user: don't adjust base of found hole
tests/avocado: add :avocado: tags for some tests
Brad Smith (1):
FreeBSD: Upgrade to 12.3 release
Daniel P. Berrangé (17):
ui: avoid compiler warnings from unused clipboard info variable
meson: require liburing >= 0.3
ui: avoid warnings about directdb on Alpine / musl libc
ci: explicitly skip I/O tests on alpine
tests/docker: switch fedora image to release 35
tests: integrate lcitool for generating build env manifests
tests/docker: auto-generate centos8.docker with lcitool
tests/docker: auto-generate fedora.docker with lcitool
tests/docker: auto-generate ubuntu1804.docker with lcitool
tests/docker: auto-generate ubuntu2004.docker with lcitool
tests/docker: auto-generate opensuse-leap.docker with lcitool
tests/docker: remove ubuntu.docker container
.gitlab-ci.d/cirrus: auto-generate variables with lcitool
tests/docker: updates to alpine package list
tests/docker: fix sorting of alpine image package lists
tests/docker: fully expand the alpine package list
tests/docker: auto-generate alpine.docker with lcitool
John Snow (1):
spice: Update QXLInterface for spice >= 0.15.0
Marc-André Lureau (1):
docs/sphinx: fix compatibility with sphinx < 1.8
Paolo Bonzini (2):
tests/tcg: use CONFIG_LINUX_USER, not CONFIG_LINUX
docker: include bison in debian-tricore-cross
Richard Henderson (2):
tests/tcg/multiarch: Read fp flags before printf
test/tcg/ppc64le: Add float reference files
Stefan Hajnoczi (1):
tests/docker: add libfuse3 development headers
Thomas Huth (2):
gitlab-ci: Enable docs in the centos job
linux-user: Remove the deprecated ppc64abi32 target
docs/about/deprecated.rst | 7 -
docs/about/removed-features.rst | 8 +
docs/devel/style.rst | 14 +-
docs/devel/testing.rst | 104 ++-
docs/sphinx/fakedbusdoc.py | 4 +-
docs/system/arm/virt.rst | 7 +
docs/user/main.rst | 1 -
configure | 29 +-
Makefile | 2 +
configs/targets/ppc64abi32-linux-user.mak | 8 -
meson.build | 3 +-
qapi/machine.json | 1 +
include/glib-compat.h | 6 +-
include/hw/arm/virt.h | 1 +
include/ui/qemu-spice.h | 6 +
include/ui/sdl2.h | 11 +
linux-user/ppc/target_syscall.h | 4 +-
linux-user/syscall_defs.h | 6 +-
accel/tcg/cpu-exec.c | 31 +
hw/arm/virt.c | 32 +-
hw/display/qxl.c | 14 +-
linux-user/elfload.c | 27 +-
linux-user/ppc/signal.c | 11 +-
monitor/qmp-cmds.c | 31 -
tests/tcg/multiarch/float_convs.c | 2 +-
tests/tcg/multiarch/float_madds.c | 2 +-
ui/clipboard.c | 4 +-
ui/spice-display.c | 11 +
.gitlab-ci.d/buildtest.yml | 31 +-
.gitlab-ci.d/cirrus.yml | 5 +-
.gitlab-ci.d/cirrus/freebsd-12.vars | 11 +-
.gitlab-ci.d/cirrus/freebsd-13.vars | 11 +-
.gitlab-ci.d/cirrus/macos-11.vars | 11 +-
.gitlab-ci.d/containers.yml | 5 -
.gitmodules | 3 +
hmp-commands-info.hx | 2 +
tests/avocado/empty_cpu_model.py | 3 +
tests/avocado/info_usernet.py | 3 +
tests/avocado/migration.py | 1 +
tests/avocado/version.py | 1 +
tests/avocado/vnc.py | 1 +
tests/docker/dockerfiles/alpine.docker | 176 ++--
tests/docker/dockerfiles/centos8.docker | 244 +++---
.../dockerfiles/debian-ppc64el-cross.docker | 2 +-
.../dockerfiles/debian-tricore-cross.docker | 1 +
tests/docker/dockerfiles/fedora.docker | 263 +++---
tests/docker/dockerfiles/opensuse-leap.docker | 246 +++---
tests/docker/dockerfiles/ubuntu.docker | 71 --
tests/docker/dockerfiles/ubuntu1804.docker | 255 +++---
tests/docker/dockerfiles/ubuntu2004.docker | 258 +++---
tests/lcitool/Makefile.include | 17 +
tests/lcitool/libvirt-ci | 1 +
tests/lcitool/projects/qemu.yml | 116 +++
tests/lcitool/refresh | 96 +++
tests/tcg/configure.sh | 10 +-
tests/tcg/hexagon/float_convs.ref | 152 ++--
tests/tcg/hexagon/float_madds.ref | 48 +-
tests/tcg/multiarch/Makefile.target | 2 +-
tests/tcg/ppc64le/float_convs.ref | 748 +++++++++++++++++
tests/tcg/ppc64le/float_madds.ref | 768 ++++++++++++++++++
tests/tcg/x86_64/Makefile.target | 2 +-
tests/vm/freebsd | 8 +-
62 files changed, 2993 insertions(+), 966 deletions(-)
delete mode 100644 configs/targets/ppc64abi32-linux-user.mak
delete mode 100644 tests/docker/dockerfiles/ubuntu.docker
create mode 100644 tests/lcitool/Makefile.include
create mode 160000 tests/lcitool/libvirt-ci
create mode 100644 tests/lcitool/projects/qemu.yml
create mode 100755 tests/lcitool/refresh
create mode 100644 tests/tcg/ppc64le/float_convs.ref
create mode 100644 tests/tcg/ppc64le/float_madds.ref
--
2.30.2
^ permalink raw reply
* [PATCH v2 2/3] SVM: sync VM-exit perf counters with known VM-exit reasons
From: Jan Beulich @ 2022-01-05 13:58 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper, Wei Liu, Roger Pau Monné
In-Reply-To: <ff461a77-93a0-5424-6565-2e947bec3912@suse.com>
This has gone out of sync over time, resulting in NPF and XSETBV exits
incrementing the same counter. Introduce a simplistic mechanism to
hopefully keep things in better sync going forward.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Use sentinel comments only.
--- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
+++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
@@ -302,7 +302,9 @@ enum VMEXIT_EXITCODE
VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */
VMEXIT_XSETBV = 141, /* 0x8d */
VMEXIT_RDPRU = 142, /* 0x8e */
+ /* Remember to also update VMEXIT_NPF_PERFC! */
VMEXIT_NPF = 1024, /* 0x400, nested paging fault */
+ /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */
VMEXIT_INVALID = -1
};
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -11,8 +11,8 @@ PERFCOUNTER_ARRAY(exceptions,
PERFCOUNTER_ARRAY(vmexits, "vmexits", VMX_PERF_EXIT_REASON_SIZE)
PERFCOUNTER_ARRAY(cause_vector, "cause vector", VMX_PERF_VECTOR_SIZE)
-#define VMEXIT_NPF_PERFC 141
-#define SVM_PERF_EXIT_REASON_SIZE (1+141)
+#define VMEXIT_NPF_PERFC 143
+#define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
PERFCOUNTER_ARRAY(svmexits, "SVMexits", SVM_PERF_EXIT_REASON_SIZE)
#endif /* CONFIG_HVM */
^ permalink raw reply
* [PATCH 0/3] mtd: rawnand: stm32_fmc2: Add NAND Write Protect support
From: Christophe Kerello @ 2022-01-05 13:57 UTC (permalink / raw)
To: miquel.raynal, richard, vigneshr, robh+dt, srinivas.kandagatla
Cc: linux-mtd, linux-kernel, linux-stm32, devicetree, chenshumin86,
Christophe Kerello
This patchset adds the management of the WP# signal in FMC2 driver.
WP will be disabled in probe/resume callbacks and will be enabled
in remove/suspend callbacks.
This patchset also fixes a conflict on wp-gpios property between
MTD and NVMEN.
Christophe Kerello (3):
dt-binding: mtd: nand: Document the wp-gpios property
mtd: rawnand: stm32_fmc2: Add NAND Write Protect support
nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property
.../bindings/mtd/nand-controller.yaml | 7 ++++
drivers/mtd/nand/raw/stm32_fmc2_nand.c | 40 ++++++++++++++++++-
drivers/nvmem/core.c | 2 +-
3 files changed, 47 insertions(+), 2 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 2/3] mtd: rawnand: stm32_fmc2: Add NAND Write Protect support
From: Christophe Kerello @ 2022-01-05 13:57 UTC (permalink / raw)
To: miquel.raynal, richard, vigneshr, robh+dt, srinivas.kandagatla
Cc: linux-mtd, linux-kernel, linux-stm32, devicetree, chenshumin86,
Christophe Kerello
In-Reply-To: <20220105135734.271313-1-christophe.kerello@foss.st.com>
This patch adds the support of the WP# signal. WP will be disabled in
probe/resume callbacks and will be enabled in remove/suspend callbacks.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
---
drivers/mtd/nand/raw/stm32_fmc2_nand.c | 40 +++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
index 97b4e02e43e4..87c1c7dd97eb 100644
--- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
+++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
@@ -9,6 +9,7 @@
#include <linux/dmaengine.h>
#include <linux/dma-mapping.h>
#include <linux/errno.h>
+#include <linux/gpio/consumer.h>
#include <linux/interrupt.h>
#include <linux/iopoll.h>
#include <linux/mfd/syscon.h>
@@ -231,6 +232,7 @@ struct stm32_fmc2_timings {
struct stm32_fmc2_nand {
struct nand_chip chip;
+ struct gpio_desc *wp_gpio;
struct stm32_fmc2_timings timings;
int ncs;
int cs_used[FMC2_MAX_CE];
@@ -1747,6 +1749,18 @@ static const struct nand_controller_ops stm32_fmc2_nfc_controller_ops = {
.setup_interface = stm32_fmc2_nfc_setup_interface,
};
+static void stm32_fmc2_nfc_wp_enable(struct stm32_fmc2_nand *nand)
+{
+ if (nand->wp_gpio)
+ gpiod_set_value(nand->wp_gpio, 1);
+}
+
+static void stm32_fmc2_nfc_wp_disable(struct stm32_fmc2_nand *nand)
+{
+ if (nand->wp_gpio)
+ gpiod_set_value(nand->wp_gpio, 0);
+}
+
static int stm32_fmc2_nfc_parse_child(struct stm32_fmc2_nfc *nfc,
struct device_node *dn)
{
@@ -1785,6 +1799,18 @@ static int stm32_fmc2_nfc_parse_child(struct stm32_fmc2_nfc *nfc,
nand->cs_used[i] = cs;
}
+ nand->wp_gpio = devm_gpiod_get_from_of_node(nfc->dev, dn,
+ "wp-gpios", 0,
+ GPIOD_OUT_HIGH, "wp");
+ if (IS_ERR(nand->wp_gpio)) {
+ ret = PTR_ERR(nand->wp_gpio);
+ if (ret != -ENOENT)
+ return dev_err_probe(nfc->dev, ret,
+ "failed to request WP GPIO\n");
+
+ nand->wp_gpio = NULL;
+ }
+
nand_set_flash_node(&nand->chip, dn);
return 0;
@@ -1956,10 +1982,12 @@ static int stm32_fmc2_nfc_probe(struct platform_device *pdev)
chip->options |= NAND_BUSWIDTH_AUTO | NAND_NO_SUBPAGE_WRITE |
NAND_USES_DMA;
+ stm32_fmc2_nfc_wp_disable(nand);
+
/* Scan to find existence of the device */
ret = nand_scan(chip, nand->ncs);
if (ret)
- goto err_release_dma;
+ goto err_wp_enable;
ret = mtd_device_register(mtd, NULL, 0);
if (ret)
@@ -1972,6 +2000,9 @@ static int stm32_fmc2_nfc_probe(struct platform_device *pdev)
err_nand_cleanup:
nand_cleanup(chip);
+err_wp_enable:
+ stm32_fmc2_nfc_wp_enable(nand);
+
err_release_dma:
if (nfc->dma_ecc_ch)
dma_release_channel(nfc->dma_ecc_ch);
@@ -2012,15 +2043,20 @@ static int stm32_fmc2_nfc_remove(struct platform_device *pdev)
clk_disable_unprepare(nfc->clk);
+ stm32_fmc2_nfc_wp_enable(nand);
+
return 0;
}
static int __maybe_unused stm32_fmc2_nfc_suspend(struct device *dev)
{
struct stm32_fmc2_nfc *nfc = dev_get_drvdata(dev);
+ struct stm32_fmc2_nand *nand = &nfc->nand;
clk_disable_unprepare(nfc->clk);
+ stm32_fmc2_nfc_wp_enable(nand);
+
pinctrl_pm_select_sleep_state(dev);
return 0;
@@ -2042,6 +2078,8 @@ static int __maybe_unused stm32_fmc2_nfc_resume(struct device *dev)
stm32_fmc2_nfc_init(nfc);
+ stm32_fmc2_nfc_wp_disable(nand);
+
for (chip_cs = 0; chip_cs < FMC2_MAX_CE; chip_cs++) {
if (!(nfc->cs_assigned & BIT(chip_cs)))
continue;
--
2.25.1
^ permalink raw reply related
* [PATCH v1 11/34] tests/docker: auto-generate ubuntu2004.docker with lcitool
From: Alex Bennée @ 2022-01-05 13:49 UTC (permalink / raw)
To: qemu-devel
Cc: fam, Thomas Huth, berrange, Beraldo Leal, Alex Bennée, f4bug,
Wainer dos Santos Moschetta, stefanha, crosa, pbonzini,
Philippe Mathieu-Daudé, aurelien
In-Reply-To: <20220105135009.1584676-1-alex.bennee@linaro.org>
From: Daniel P. Berrangé <berrange@redhat.com>
This commit is best examined using the "-b" option to diff.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20211215141949.3512719-12-berrange@redhat.com>
---
tests/docker/dockerfiles/ubuntu2004.docker | 257 ++++++++++++---------
tests/lcitool/refresh | 9 +-
2 files changed, 151 insertions(+), 115 deletions(-)
diff --git a/tests/docker/dockerfiles/ubuntu2004.docker b/tests/docker/dockerfiles/ubuntu2004.docker
index 15a026be09..40402b91fe 100644
--- a/tests/docker/dockerfiles/ubuntu2004.docker
+++ b/tests/docker/dockerfiles/ubuntu2004.docker
@@ -1,119 +1,148 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+# $ lcitool dockerfile ubuntu-2004 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
FROM docker.io/library/ubuntu:20.04
-ENV PACKAGES \
- bc \
- bsdmainutils \
- bzip2 \
- ca-certificates \
- ccache \
- clang \
- dbus \
- debianutils \
- diffutils \
- exuberant-ctags \
- findutils \
- g++ \
- gcc \
- gcovr \
- genisoimage \
- gettext \
- git \
- hostname \
- libaio-dev \
- libasan5 \
- libasound2-dev \
- libattr1-dev \
- libbrlapi-dev \
- libbz2-dev \
- libc6-dev \
- libcacard-dev \
- libcap-ng-dev \
- libcapstone-dev \
- libcurl4-gnutls-dev \
- libdaxctl-dev \
- libdrm-dev \
- libepoxy-dev \
- libfdt-dev \
- libffi-dev \
- libgbm-dev \
- libgcrypt20-dev \
- libglib2.0-dev \
- libglusterfs-dev \
- libgnutls28-dev \
- libgtk-3-dev \
- libibverbs-dev \
- libiscsi-dev \
- libjemalloc-dev \
- libjpeg-turbo8-dev \
- liblttng-ust-dev \
- liblzo2-dev \
- libncursesw5-dev \
- libnfs-dev \
- libnuma-dev \
- libpam0g-dev \
- libpixman-1-dev \
- libpmem-dev \
- libpng-dev \
- libpulse-dev \
- librbd-dev \
- librdmacm-dev \
- libsasl2-dev \
- libsdl2-dev \
- libsdl2-image-dev \
- libseccomp-dev \
- libselinux-dev \
- libslirp-dev \
- libsnappy-dev \
- libspice-protocol-dev \
- libspice-server-dev \
- libssh-dev \
- libsystemd-dev \
- libtasn1-6-dev \
- libtest-harness-perl \
- libubsan1 \
- libudev-dev \
- libusb-1.0-0-dev \
- libusbredirhost-dev \
- libvdeplug-dev \
- libvirglrenderer-dev \
- libvte-2.91-dev \
- libxen-dev \
- libxml2-dev \
- libzstd-dev \
- llvm \
- locales \
- make \
- multipath-tools \
- ncat \
- nettle-dev \
- ninja-build \
- openssh-client \
- perl-base \
- pkgconf \
- python3 \
- python3-numpy \
- python3-opencv \
- python3-pillow \
- python3-pip \
- python3-setuptools \
- python3-sphinx \
- python3-sphinx-rtd-theme \
- python3-venv \
- python3-wheel \
- python3-yaml \
- rpm2cpio \
- sed \
- sparse \
- systemtap-sdt-dev \
- tar \
- tesseract-ocr \
- tesseract-ocr-eng \
- texinfo \
- xfslibs-dev \
- zlib1g-dev
-RUN apt-get update && \
- DEBIAN_FRONTEND=noninteractive apt-get -y install $PACKAGES
-RUN dpkg -l $PACKAGES | sort > /packages.txt
+RUN export DEBIAN_FRONTEND=noninteractive && \
+ apt-get update && \
+ apt-get install -y eatmydata && \
+ eatmydata apt-get dist-upgrade -y && \
+ eatmydata apt-get install --no-install-recommends -y \
+ bash \
+ bc \
+ bsdmainutils \
+ bzip2 \
+ ca-certificates \
+ ccache \
+ clang \
+ dbus \
+ debianutils \
+ diffutils \
+ exuberant-ctags \
+ findutils \
+ g++ \
+ gcc \
+ gcovr \
+ genisoimage \
+ gettext \
+ git \
+ hostname \
+ libaio-dev \
+ libasan5 \
+ libasound2-dev \
+ libattr1-dev \
+ libbrlapi-dev \
+ libbz2-dev \
+ libc6-dev \
+ libcacard-dev \
+ libcap-ng-dev \
+ libcapstone-dev \
+ libcurl4-gnutls-dev \
+ libdaxctl-dev \
+ libdrm-dev \
+ libepoxy-dev \
+ libfdt-dev \
+ libffi-dev \
+ libgbm-dev \
+ libgcrypt20-dev \
+ libglib2.0-dev \
+ libglusterfs-dev \
+ libgnutls28-dev \
+ libgtk-3-dev \
+ libibverbs-dev \
+ libiscsi-dev \
+ libjemalloc-dev \
+ libjpeg-turbo8-dev \
+ liblttng-ust-dev \
+ liblzo2-dev \
+ libncursesw5-dev \
+ libnfs-dev \
+ libnuma-dev \
+ libpam0g-dev \
+ libpcre2-dev \
+ libpixman-1-dev \
+ libpmem-dev \
+ libpng-dev \
+ libpulse-dev \
+ librbd-dev \
+ librdmacm-dev \
+ libsasl2-dev \
+ libsdl2-dev \
+ libsdl2-image-dev \
+ libseccomp-dev \
+ libselinux1-dev \
+ libslirp-dev \
+ libsnappy-dev \
+ libspice-protocol-dev \
+ libspice-server-dev \
+ libssh-dev \
+ libsystemd-dev \
+ libtasn1-6-dev \
+ libtest-harness-perl \
+ libubsan1 \
+ libudev-dev \
+ libusb-1.0-0-dev \
+ libusbredirhost-dev \
+ libvdeplug-dev \
+ libvirglrenderer-dev \
+ libvte-2.91-dev \
+ libxen-dev \
+ libxml2-dev \
+ libzstd-dev \
+ llvm \
+ locales \
+ make \
+ multipath-tools \
+ ncat \
+ nettle-dev \
+ ninja-build \
+ openssh-client \
+ perl-base \
+ pkgconf \
+ python3 \
+ python3-numpy \
+ python3-opencv \
+ python3-pillow \
+ python3-pip \
+ python3-setuptools \
+ python3-sphinx \
+ python3-sphinx-rtd-theme \
+ python3-venv \
+ python3-wheel \
+ python3-yaml \
+ rpm2cpio \
+ sed \
+ sparse \
+ systemtap-sdt-dev \
+ tar \
+ tesseract-ocr \
+ tesseract-ocr-eng \
+ texinfo \
+ xfslibs-dev \
+ zlib1g-dev && \
+ eatmydata apt-get autoremove -y && \
+ eatmydata apt-get autoclean -y && \
+ sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \
+ dpkg-reconfigure locales && \
+ dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt && \
+ mkdir -p /usr/libexec/ccache-wrappers && \
+ ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/c++ && \
+ ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \
+ ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/clang && \
+ ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/g++ && \
+ ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/gcc
+
+RUN pip3 install \
+ meson==0.56.0
+
+ENV LANG "en_US.UTF-8"
+ENV MAKE "/usr/bin/make"
+ENV NINJA "/usr/bin/ninja"
+ENV PYTHON "/usr/bin/python3"
+ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers"
# Apply patch https://reviews.llvm.org/D75820
# This is required for TSan in clang-10 to compile with QEMU.
RUN sed -i 's/^const/static const/g' /usr/lib/llvm-10/lib/clang/10.0.0/include/sanitizer/tsan_interface.h
diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index 1e30674d67..310bad1315 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -65,12 +65,19 @@ ubuntu1804_skipssh = [
"ENV QEMU_CONFIGURE_OPTS --disable-libssh\n"
]
+ubuntu2004_tsanhack = [
+ "# Apply patch https://reviews.llvm.org/D75820\n",
+ "# This is required for TSan in clang-10 to compile with QEMU.\n",
+ "RUN sed -i 's/^const/static const/g' /usr/lib/llvm-10/lib/clang/10.0.0/include/sanitizer/tsan_interface.h\n"
+]
+
try:
generate_dockerfile("centos8", "centos-8")
generate_dockerfile("fedora", "fedora-35")
generate_dockerfile("ubuntu1804", "ubuntu-1804",
trailer="".join(ubuntu1804_skipssh))
-
+ generate_dockerfile("ubuntu2004", "ubuntu-2004",
+ trailer="".join(ubuntu2004_tsanhack))
sys.exit(0)
except Exception as ex:
print(str(ex), file=sys.stderr)
--
2.30.2
^ permalink raw reply related
* [PATCH 1/3] dt-binding: mtd: nand: Document the wp-gpios property
From: Christophe Kerello @ 2022-01-05 13:57 UTC (permalink / raw)
To: miquel.raynal, richard, vigneshr, robh+dt, srinivas.kandagatla
Cc: linux-mtd, linux-kernel, linux-stm32, devicetree, chenshumin86,
Christophe Kerello
In-Reply-To: <20220105135734.271313-1-christophe.kerello@foss.st.com>
A few drivers use this property to describe the GPIO pin used to protect
the NAND during program/erase operations.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
---
Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index bd217e6f5018..53b21aed0ac5 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -154,6 +154,13 @@ patternProperties:
Ready/Busy pins. Active state refers to the NAND ready state and
should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
+ wp-gpios:
+ description:
+ Contains one GPIO descriptor for the Write Protect pin.
+ Active state refers to the NAND Write Protect state and should be
+ set to GPIOD_ACTIVE_LOW unless the signal is inverted.
+ maxItems: 1
+
secure-regions:
$ref: /schemas/types.yaml#/definitions/uint64-matrix
description:
--
2.25.1
^ permalink raw reply related
* [PATCH 3/3] nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property
From: Christophe Kerello @ 2022-01-05 13:57 UTC (permalink / raw)
To: miquel.raynal, richard, vigneshr, robh+dt, srinivas.kandagatla
Cc: linux-mtd, linux-kernel, linux-stm32, devicetree, chenshumin86,
Christophe Kerello
In-Reply-To: <20220105135734.271313-1-christophe.kerello@foss.st.com>
Wp-gpios property can be used on NVMEN nodes and the same property can
be also used on MTD NAND nodes. In case of the wp-gpios property is
defined at NAND level node, the GPIO management is done at NAND driver
level. Write protect is disabled when the driver is probed or resumed
and is enabled when the driver is released or suspended.
When no partitions are defined in the NAND DT node, then the NAND DT node
will be passed to NVMEM framework. If wp-gpios property is defined in
this node, the GPIO resource is taken twice and the NAND controller
driver fails to probe.
It would be possible to set config->wp_gpio at MTD level before calling
nvmem_register function but NVMEM framework will toggled this GPIO on
each write when this GPIO should only be controlled at NAND level driver
to ensure that the Write Protect has not been enabled.
As MTD framework is only using NVMEN framework in read only, a way to fix
this conflict is to get the GPIO resource at NVMEM level only if reg_write
API is defined. This GPIO is only toggled if reg_write ops is defined.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
---
drivers/nvmem/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index e765d3d0542e..e11c74db64f9 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -769,7 +769,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
if (config->wp_gpio)
nvmem->wp_gpio = config->wp_gpio;
- else
+ else if (config->reg_write)
nvmem->wp_gpio = gpiod_get_optional(config->dev, "wp",
GPIOD_OUT_HIGH);
if (IS_ERR(nvmem->wp_gpio)) {
--
2.25.1
^ permalink raw reply related
* [PATCH v2 3/3] x86/perfc: fold HVM's VM-exit counter arrays
From: Jan Beulich @ 2022-01-05 13:59 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper, Wei Liu, Roger Pau Monné
In-Reply-To: <ff461a77-93a0-5424-6565-2e947bec3912@suse.com>
Only one of them can be in use at a time, so make the whole set union-
like. While doing the rename in SVM code, combine the two perf_incra(),
generalizing the range upwards of VMEXIT_NPF.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2644,7 +2644,10 @@ void svm_vmexit_handler(struct cpu_user_
goto out;
}
- perfc_incra(svmexits, exit_reason);
+ perfc_incra(vmexits,
+ exit_reason < VMEXIT_NPF
+ ? exit_reason
+ : exit_reason - VMEXIT_NPF + VMEXIT_NPF_PERFC);
hvm_maybe_deassert_evtchn_irq();
@@ -2973,7 +2976,6 @@ void svm_vmexit_handler(struct cpu_user_
break;
case VMEXIT_NPF:
- perfc_incra(svmexits, VMEXIT_NPF_PERFC);
if ( cpu_has_svm_decode )
v->arch.hvm.svm.cached_insn_len = vmcb->guest_ins_len & 0xf;
rc = vmcb->exitinfo1 & PFEC_page_present
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -7,13 +7,13 @@ PERFCOUNTER_ARRAY(exceptions,
#ifdef CONFIG_HVM
#define VMX_PERF_EXIT_REASON_SIZE 65
-#define VMX_PERF_VECTOR_SIZE 0x20
-PERFCOUNTER_ARRAY(vmexits, "vmexits", VMX_PERF_EXIT_REASON_SIZE)
-PERFCOUNTER_ARRAY(cause_vector, "cause vector", VMX_PERF_VECTOR_SIZE)
-
#define VMEXIT_NPF_PERFC 143
#define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
-PERFCOUNTER_ARRAY(svmexits, "SVMexits", SVM_PERF_EXIT_REASON_SIZE)
+PERFCOUNTER_ARRAY(vmexits, "vmexits",
+ MAX(VMX_PERF_EXIT_REASON_SIZE, SVM_PERF_EXIT_REASON_SIZE))
+
+#define VMX_PERF_VECTOR_SIZE 0x20
+PERFCOUNTER_ARRAY(cause_vector, "cause vector", VMX_PERF_VECTOR_SIZE)
#endif /* CONFIG_HVM */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.