Stream: git-wasmtime

Topic: wasmtime / issue #3310 Missing cache maintenance and cont...

Wasmtime GitHub notifications bot (Sep 07 2021 at 18:14):

akirilov-arm opened issue #3310:

Currently (as of commit 164835ecf5adadc811937b85dc51088f0ee5457f), after code generation is finished and before execution from the newly generated code starts on AArch64, both cranelift-jit and wasmtime-jit do not perform any actions other than making the code buffers readable and executable instead of readable and writable. In particular, they skip all the actions prescribed by the Arm Architecture Reference Manual in sections B2.2.5 and B.2.4.4.

This issue has already been discussed on Zulip, and potentially would affect other architectures with weak memory models (and non-coherent data and instruction caches in particular).

Wasmtime GitHub notifications bot (Sep 07 2021 at 18:34):

akirilov-arm edited issue #3310:

Currently (as of commit 164835ecf5adadc811937b85dc51088f0ee5457f), after code generation is finished and before execution from the newly generated code starts on AArch64, both cranelift-jit and wasmtime-jit do not perform any actions other than making the code buffers readable and executable instead of readable and writable. In particular, they skip all the actions prescribed by the Arm Architecture Reference Manual in sections B2.2.5 and B.2.4.4. On Linux from C code, for example, it is sufficient to perform a call to the __builtin___clear_cache() function on the code buffers and, if we are in a multi-threaded environment (which is the case for Wasmtime), another call to membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, 0).

This issue has already been discussed on Zulip, and potentially would affect other architectures with weak memory models (and non-coherent data and instruction caches in particular).

Wasmtime GitHub notifications bot (Sep 10 2021 at 16:40):

akirilov-arm labeled issue #3310:

Currently (as of commit 164835ecf5adadc811937b85dc51088f0ee5457f), after code generation is finished and before execution from the newly generated code starts on AArch64, both cranelift-jit and wasmtime-jit do not perform any actions other than making the code buffers readable and executable instead of readable and writable. In particular, they skip all the actions prescribed by the Arm Architecture Reference Manual in sections B2.2.5 and B.2.4.4. On Linux from C code, for example, it is sufficient to perform a call to the __builtin___clear_cache() function on the code buffers and, if we are in a multi-threaded environment (which is the case for Wasmtime), another call to membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, 0).

This issue has already been discussed on Zulip, and potentially would affect other architectures with weak memory models (and non-coherent data and instruction caches in particular).

Wasmtime GitHub notifications bot (Sep 10 2021 at 16:40):

akirilov-arm labeled issue #3310:

Currently (as of commit 164835ecf5adadc811937b85dc51088f0ee5457f), after code generation is finished and before execution from the newly generated code starts on AArch64, both cranelift-jit and wasmtime-jit do not perform any actions other than making the code buffers readable and executable instead of readable and writable. In particular, they skip all the actions prescribed by the Arm Architecture Reference Manual in sections B2.2.5 and B.2.4.4. On Linux from C code, for example, it is sufficient to perform a call to the __builtin___clear_cache() function on the code buffers and, if we are in a multi-threaded environment (which is the case for Wasmtime), another call to membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, 0).

This issue has already been discussed on Zulip, and potentially would affect other architectures with weak memory models (and non-coherent data and instruction caches in particular).

Wasmtime GitHub notifications bot (Sep 17 2021 at 22:31):

sunfishcode commented on issue #3310:

With #3355, Wasmtime now uses rsix for some of its system calls. I added a membarrier API to rsix 0.23.2, so this can now be implemented using the rsix::process::membarrier function.

Wasmtime GitHub notifications bot (Sep 17 2021 at 22:48):

sunfishcode edited a comment on issue #3310:

With #3355, Wasmtime now uses rsix for some of its system calls. I added a membarrier API to rsix 0.23.2, so this can now be implemented using the rsix::process::membarrier function.

Last updated: Dec 23 2024 at 12:05 UTC