Re: [PATCH v2 5/7] 9pfs: fix 'Twalk' to only send error if no component walked

On Samstag, 12. März 2022 12:06:47 CET Christian Schoenebeck wrote: > Current implementation of 'Twalk' request handling always sends an 'Rerror' > response if any error occured. The 9p2000 protocol spec says though: > > " > If the first element cannot be walked for any reason, Rerror is retur

[PATCH v3 0/7] 9pfs: fix 'Twalk' protocol violation

Currently the implementation of 'Twalk' does not behave exactly as specified by the 9p2000 protocol specification. Actual fix is patch 5; see the description of that patch for details of what this overall fix and series is about. Patch 4 is a preparatory (pure) refactoring change to make patch 5 b

[PATCH v3 2/7] tests/9pfs: Twalk with nwname=0

Send Twalk request with nwname=0. In this case no QIDs should be returned by 9p server; this is equivalent to walking to dot. Signed-off-by: Christian Schoenebeck Reviewed-by: Greg Kurz --- tests/qtest/virtio-9p-test.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/

[PATCH v3 3/7] tests/9pfs: compare QIDs in fs_walk_none() test

Extend previously added fs_walk_none() test by comparing the QID of the root fid with the QID of the cloned fid. They should be equal. Signed-off-by: Christian Schoenebeck --- tests/qtest/virtio-9p-test.c | 87 1 file changed, 87 insertions(+) diff --git a/t

[PATCH v3 5/7] 9pfs: fix 'Twalk' to only send error if no component walked

Current implementation of 'Twalk' request handling always sends an 'Rerror' response if any error occured. The 9p2000 protocol spec says though: " If the first element cannot be walked for any reason, Rerror is returned. Otherwise, the walk will return an Rwalk message containing nwqid qids

[PATCH v3 1/7] tests/9pfs: walk to non-existent dir

Expect ENOENT Rlerror response when trying to walk to a non-existent directory. Signed-off-by: Christian Schoenebeck Reviewed-by: Greg Kurz --- tests/qtest/virtio-9p-test.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/tests/qtest/virtio-9p-test.c b/tests/q

[PATCH v3 7/7] tests/9pfs: check fid being unaffected in fs_walk_2nd_nonexistent

Extend previously added test case by checking that fid is unaffected by 'Twalk' request (i.e. when 2nd path component of request being invalid). Do that by comparing the QID of root fid with QID of walked fid; they should be identical. Signed-off-by: Christian Schoenebeck --- tests/qtest/virtio-

[PATCH v3 4/7] 9pfs: refactor 'name_idx' -> 'nwalked' in v9fs_walk()

The local variable 'name_idx' is used in two loops in function v9fs_walk(). Let the first loop use its own variable 'nwalked' instead, which we will use in subsequent patch as the number of (requested) path components successfully walked by background I/O thread. Signed-off-by: Christian Schoenebe

[PATCH v3 6/7] tests/9pfs: guard recent 'Twalk' behaviour fix

Previous 9p patch fixed 'Twalk' request handling, which was previously not behaving as specified by the 9p2000 protocol spec. This patch adds a new test case which guards the new 'Twalk' behaviour in question. More specifically: it sends a 'Twalk' request where the 1st path component is valid, whe

Re: [PATCH v3 7/7] tests/9pfs: check fid being unaffected in fs_walk_2nd_nonexistent

On Sonntag, 13. März 2022 10:28:32 CET Christian Schoenebeck wrote: > Extend previously added test case by checking that fid is unaffected > by 'Twalk' request (i.e. when 2nd path component of request being > invalid). Do that by comparing the QID of root fid with QID of walked > fid; they should b

RE: [PATCH v5 41/48] target/nios2: Introduce shadow register sets

(Continue discussion from Re: [PATCH v4 24/33] target/nios2: Introduce shadow register sets) > > How does "cpu_crs_R" work? > > ... Otherwise, each gpr access would be indirect. I'm probably missing > > something here. > They are indirect, but with some optimization. Why not always access dire

Re: [PATCH v3 7/7] tests/9pfs: check fid being unaffected in fs_walk_2nd_nonexistent

On Sonntag, 13. März 2022 11:27:56 CET Christian Schoenebeck wrote: > On Sonntag, 13. März 2022 10:28:32 CET Christian Schoenebeck wrote: > > Extend previously added test case by checking that fid is unaffected > > by 'Twalk' request (i.e. when 2nd path component of request being > > invalid). Do t

Re: [PATCH v2 04/11] edk2: .git can be a file

On 11/3/22 06:37, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann --- roms/Makefile.edk2 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v2 09/11] edk2/docker: install python3

On 11/3/22 06:37, Gerd Hoffmann wrote: python2 is not supported any more, so go install python3 instead. Signed-off-by: Gerd Hoffmann Reviewed-by: Alex Bennée --- .gitlab-ci.d/edk2/Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v2 10/11] edk2/docker: use ubuntu 18.04

On 11/3/22 06:37, Gerd Hoffmann wrote: Upstream CI uses ubuntu 18.04 too, so pick that version (instead of something newer). Signed-off-by: Gerd Hoffmann Reviewed-by: Alex Bennée --- .gitlab-ci.d/edk2/Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Philippe M

Re: [RFC PATCH] mailmap/gitdm: more fixes for bad tags and authors

On 11/3/22 14:52, Alex Bennée wrote: I was running some historical tags for the last 10 years and got the following warnings: git log --use-mailmap --numstat --since "June 2010" | ~/src/gitdm.git/gitdm -n -l 5 alar...@ddci.com is an author name, probably not what you want bad utf-8 ('u

Re: [PATCH] ppc/xive2: Make type Xive2EndSource not user creatable

On 11/3/22 08:43, Cédric Le Goater wrote: Xive2EndSource objects can only be instantiated through a Xive2Router (PnvXive2). Suggested-by: Thomas Huth Reported-by? Signed-off-by: Cédric Le Goater --- hw/intc/xive2.c | 1 + 1 file changed, 1 insertion(+) Reviewed-by: Philippe Mathieu-Da

Re: [PATCH experiment 00/35] stackless coroutine backend

On 3/11/22 13:17, Daniel P. Berrangé wrote: Only files that define or use a coroutine_fn (which includes callers of qemu_coroutine_create) would have to be compiled as C++. Unless I'm misunderstanding what you mean, "define a coroutine_fn" is a very large number of functions/files $ git grep

Re: Question about atomics

On 3/12/22 20:59, Warner Losh wrote: FreeBSD's pthread_mutex is shared between the kernel and user land. So it does a compare and set to take the lock. Uncontested and unheld locks will mean we've taken the lock and return. Contested locks are kicked to the kernel to wait. When userland releases

Re: [PATCH v5 41/48] target/nios2: Introduce shadow register sets

On 3/13/22 04:55, Amir Gonnen wrote: (Continue discussion from Re: [PATCH v4 24/33] target/nios2: Introduce shadow register sets) How does "cpu_crs_R" work? ... Otherwise, each gpr access would be indirect. I'm probably missing something here. They are indirect, but with some optimization.

Re: Question about atomics

On Sun, Mar 13, 2022, 10:47 AM Richard Henderson < richard.hender...@linaro.org> wrote: > On 3/12/22 20:59, Warner Losh wrote: > > FreeBSD's pthread_mutex is shared between the kernel and user land. > > So it does a compare and set to take the lock. Uncontested and unheld > > locks will mean we've

Re: Question about atomics

On 3/13/22 09:57, Warner Losh wrote: On Sun, Mar 13, 2022, 10:47 AM Richard Henderson > wrote: On 3/12/22 20:59, Warner Losh wrote: > FreeBSD's pthread_mutex is shared between the kernel and user land. > So it does a compare and set to take t

Re: Question about atomics

On Sun, Mar 13, 2022 at 11:03 AM Richard Henderson < richard.hender...@linaro.org> wrote: > On 3/13/22 09:57, Warner Losh wrote: > > > > > > On Sun, Mar 13, 2022, 10:47 AM Richard Henderson < > richard.hender...@linaro.org > > > wrote: > > > > On 3/12/22 20

Re: Question about atomics

On 3/13/22 11:29, Warner Losh wrote: So I was assuming that the cas instructions for arm use start/end_exclsive under the covers. Is that the case? Nope. The store exclusive guest insn is implemented with a host cmpxchg. Oh, I'd forgotten about the old arm cmpxchg64 syscall, which is still i

Re: Question about atomics

On Sun, Mar 13, 2022 at 2:19 PM Richard Henderson < richard.hender...@linaro.org> wrote: > On 3/13/22 11:29, Warner Losh wrote: > > So I was assuming that the cas instructions for arm use > start/end_exclsive under the covers. > > Is that the case? > > Nope. The store exclusive guest insn is impl

Re: Question about atomics

On 3/13/22 21:09, Warner Losh wrote: Oh? Out of paranoia, how can I verify that this is the case when compiled on FreeBSD? Perhaps the atomic sequence FreeBSD uses differs a little from Linux and we don't trigger that code? $ objdump -dr libqemu-arm-*-user.fa.p/accel_tcg_user-exec.c.o 00

[PATCH 0/3] linux-user/arm: Improvements for commpage atomics

Only the memory_barrer one is a bug; the rest improve system-wide interaction, and would only affect pre-armv6. r~ Richard Henderson (3): linux-user/arm: Implement __kernel_memory_barrier linux-user/arm: Implement __kernel_cmpxchg with host atomics linux-user/arm: Implement __kernel_cmpxc

[PATCH 3/3] linux-user/arm: Implement __kernel_cmpxchg64 with host atomics

If CONFIG_ATOMIC64, we can use a host cmpxchg and provide atomicity across processes; otherwise we have no choice but to continue using start/end_exclusive. Signed-off-by: Richard Henderson --- linux-user/arm/cpu_loop.c | 79 +++ 1 file changed, 38 insertions(

[PATCH 1/3] linux-user/arm: Implement __kernel_memory_barrier

This fallback syscall was stubbed out. It would only matter for emulating pre-armv6. Signed-off-by: Richard Henderson --- linux-user/arm/cpu_loop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/linux-user/arm/cpu_loop.c b/linux-user/arm/cpu_loop.c index 032e1ffddf..a0e43b26

Re: Question about atomics

On 3/13/22 21:09, Warner Losh wrote: Oh? Out of paranoia, how can I verify that this is the case when compiled on FreeBSD? Perhaps the atomic sequence FreeBSD uses differs a little from Linux and we don't trigger that code? Or there's some adjustment that I've not made yet... the code seems to

[PATCH 2/3] linux-user/arm: Implement __kernel_cmpxchg with host atomics

The existing implementation using start/end_exclusive does not provide atomicity across processes. Signed-off-by: Richard Henderson --- linux-user/arm/cpu_loop.c | 85 +++ 1 file changed, 60 insertions(+), 25 deletions(-) diff --git a/linux-user/arm/cpu_loop.

Re: Question about atomics

On Sun, Mar 13, 2022 at 10:43 PM Richard Henderson < richard.hender...@linaro.org> wrote: > On 3/13/22 21:09, Warner Losh wrote: > > Oh? Out of paranoia, how can I verify that this is the case when > compiled on FreeBSD? > > Perhaps the atomic sequence FreeBSD uses differs a little from Linux and

Re: Question about atomics

On Sun, Mar 13, 2022 at 10:36 PM Richard Henderson < richard.hender...@linaro.org> wrote: > On 3/13/22 21:09, Warner Losh wrote: > > Oh? Out of paranoia, how can I verify that this is the case when > compiled on FreeBSD? > > Perhaps the atomic sequence FreeBSD uses differs a little from Linux and

Re: [RFC v4 01/21] vfio-user: introduce vfio-user protocol specification

> On Mar 9, 2022, at 2:34 PM, Alex Williamson > wrote: > >> >> + >> +VFIO region info type cap >> +" >> + >> +The VFIO region info type is defined in >> +(``struct vfio_region_info_cap_type``). >> + >> ++-++--+ >> +| Name| Offset | Size | >

Re: [PATCH v2 0/3] hw/arm/virt: Fix CPU's default NUMA node ID

Hi Igor, On 3/3/22 11:11 AM, Gavin Shan wrote: When the CPU-to-NUMA association isn't provided by user, the default NUMA node ID for the specific CPU is returned from virt_get_default_cpu_node_id(). Unfortunately, the default NUMA node ID breaks socket boundary and leads to the broken CPU topolo