July 2026 - Wine-Devel - list.winehq.org

Upcoming vkd3d 2.1 release

by Henri Verbeet

Hi all, The planned release date for vkd3d 2.1 is Monday August 24. That means the public API will become frozen next week on July 27, and features will be frozen two weeks before the release, on August 10. This does not mean that development should slow down or stop, of course; after making sure that we're in good shape to release, this would be the ideal time to make sure that any larger features are ready to get merged at the start of the next development cycle. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify that all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Get any larger features ready to get merged at the start of the next development cycle. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 2.2 is Monday November 23. A tentative release schedule for future releases can be found on the vkd3d wiki[1]. Regards, Henri [1] https://gitlab.winehq.org/wine/vkd3d/-/wikis/release-schedule

July 20, 2026

[PATCH 4/4] ntsync: reject wait ioctls with zero owner

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> setup_wait() already validates pad and flags but not owner, while Documentation/userspace-api/ntsync.rst requires EINVAL when owner is zero. Reject early before queueing waiters. Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- drivers/misc/ntsync.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c index 02c9d1192812..4a805919bb0c 100644 --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -875,6 +875,9 @@ static int setup_wait(struct ntsync_device *dev, if (args->pad || (args->flags & ~NTSYNC_WAIT_REALTIME)) return -EINVAL; + if (!args->owner) + return -EINVAL; + if (size >= sizeof(fds)) return -EINVAL; -- 2.53.0

July 20, 2026

[PATCH 3/4] selftests: ntsync: add wait argument validation tests

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Add coverage for documented EINVAL cases: zero owner on wait any/all, non-zero pad, and objects from a different /dev/ntsync instance. Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- .../testing/selftests/drivers/ntsync/ntsync.c | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c index 12b4b81edf7f..c9fe4d5987ec 100644 --- a/tools/testing/selftests/drivers/ntsync/ntsync.c +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c @@ -1340,4 +1340,48 @@ TEST(stress_wait) close(stress_device); } +TEST(wait_args_validation) +{ + struct ntsync_sem_args sem_args = { .count = 1, .max = 1 }; + struct ntsync_wait_args wait_args = {0}; + struct timespec timeout; + int fd, fd2, sem, ret; + __u32 index; + + fd = open("/dev/ntsync", O_CLOEXEC | O_RDONLY); + ASSERT_GE(fd, 0); + + fd2 = open("/dev/ntsync", O_CLOEXEC | O_RDONLY); + ASSERT_GE(fd2, 0); + + sem = ioctl(fd, NTSYNC_IOC_CREATE_SEM, &sem_args); + EXPECT_GE(sem, 0); + + ret = wait_any(fd, 1, &sem, 0, &index); + EXPECT_EQ(-1, ret); + EXPECT_EQ(EINVAL, errno); + + ret = wait_all(fd, 1, &sem, 0, &index); + EXPECT_EQ(-1, ret); + EXPECT_EQ(EINVAL, errno); + + clock_gettime(CLOCK_MONOTONIC, &timeout); + wait_args.timeout = timeout.tv_sec * 1000000000ULL + timeout.tv_nsec; + wait_args.count = 0; + wait_args.objs = 0; + wait_args.owner = 123; + wait_args.pad = 1; + ret = ioctl(fd, NTSYNC_IOC_WAIT_ANY, &wait_args); + EXPECT_EQ(-1, ret); + EXPECT_EQ(EINVAL, errno); + + ret = wait_any(fd2, 1, &sem, 123, &index); + EXPECT_EQ(-1, ret); + EXPECT_EQ(EINVAL, errno); + + close(sem); + close(fd2); + close(fd); +} + TEST_HARNESS_MAIN -- 2.53.0

July 20, 2026

[PATCH 2/4] selftests: ntsync: fix wake_all CREATE_EVENT fd expectation

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> wake_all used EXPECT_EQ(0, objs[3]) after NTSYNC_IOC_CREATE_EVENT. The ioctl returns a non-negative file descriptor on success; check EXPECT_LE(0, objs[3]) like the other CREATE_* paths. The incorrect expectation was noted on list (Mar 2025) but is still present in mainline. Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c index e6a37214aa46..12b4b81edf7f 100644 --- a/tools/testing/selftests/drivers/ntsync/ntsync.c +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c @@ -968,7 +968,7 @@ TEST(wake_all) auto_event_args.manual = false; auto_event_args.signaled = true; objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); - EXPECT_EQ(0, objs[3]); + EXPECT_LE(0, objs[3]); wait_args.timeout = get_abs_timeout(1000); wait_args.objs = (uintptr_t)objs; -- 2.53.0

July 20, 2026

[PATCH 1/4] docs: ntsync: align uAPI ioctl names and struct layout with ntsync.h

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> The userspace-api reference used stale macro names (SEM_POST, SET_EVENT, READ_*, KILL_OWNER) and struct field order that did not match include/uapi/linux/ntsync.h. Update the documentation to match the published uapi so Wine and other consumers grep the correct symbols. Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- Documentation/userspace-api/ntsync.rst | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/userspace-api/ntsync.rst b/Documentation/userspace-api/ntsync.rst index 25e7c4aef968..535585331380 100644 --- a/Documentation/userspace-api/ntsync.rst +++ b/Documentation/userspace-api/ntsync.rst @@ -83,18 +83,18 @@ structures used in ioctl calls:: }; struct ntsync_event_args { - __u32 signaled; __u32 manual; + __u32 signaled; }; struct ntsync_wait_args { __u64 timeout; __u64 objs; __u32 count; - __u32 owner; __u32 index; - __u32 alert; __u32 flags; + __u32 owner; + __u32 alert; __u32 pad; }; @@ -152,7 +152,7 @@ The ioctls on the device file are as follows: The ioctls on the individual objects are as follows: -.. c:macro:: NTSYNC_IOC_SEM_POST +.. c:macro:: NTSYNC_IOC_SEM_RELEASE Post to a semaphore object. Takes a pointer to a 32-bit integer, which on input holds the count to be added to the semaphore, and on @@ -186,7 +186,7 @@ The ioctls on the individual objects are as follows: unowned and signaled, and eligible threads waiting on it will be woken as appropriate. -.. c:macro:: NTSYNC_IOC_SET_EVENT +.. c:macro:: NTSYNC_IOC_EVENT_SET Signal an event object. Takes a pointer to a 32-bit integer, which on output contains the previous state of the event. @@ -194,12 +194,12 @@ The ioctls on the individual objects are as follows: Eligible threads will be woken, and auto-reset events will be designaled appropriately. -.. c:macro:: NTSYNC_IOC_RESET_EVENT +.. c:macro:: NTSYNC_IOC_EVENT_RESET Designal an event object. Takes a pointer to a 32-bit integer, which on output contains the previous state of the event. -.. c:macro:: NTSYNC_IOC_PULSE_EVENT +.. c:macro:: NTSYNC_IOC_EVENT_PULSE Wake threads waiting on an event object while leaving it in an unsignaled state. Takes a pointer to a 32-bit integer, which on @@ -213,7 +213,7 @@ The ioctls on the individual objects are as follows: afterwards, and a simultaneous read operation will always report the event as unsignaled. -.. c:macro:: NTSYNC_IOC_READ_SEM +.. c:macro:: NTSYNC_IOC_SEM_READ Read the current state of a semaphore object. Takes a pointer to struct :c:type:`ntsync_sem_args`, which is used as follows: @@ -225,7 +225,7 @@ The ioctls on the individual objects are as follows: * - ``max`` - On output, contains the maximum count of the semaphore. -.. c:macro:: NTSYNC_IOC_READ_MUTEX +.. c:macro:: NTSYNC_IOC_MUTEX_READ Read the current state of a mutex object. Takes a pointer to struct :c:type:`ntsync_mutex_args`, which is used as follows: @@ -242,7 +242,7 @@ The ioctls on the individual objects are as follows: ``EOWNERDEAD``. In this case, ``count`` and ``owner`` are set to zero. -.. c:macro:: NTSYNC_IOC_READ_EVENT +.. c:macro:: NTSYNC_IOC_EVENT_READ Read the current state of an event object. Takes a pointer to struct :c:type:`ntsync_event_args`, which is used as follows: @@ -255,7 +255,7 @@ The ioctls on the individual objects are as follows: - On output, contains 1 if the event is a manual-reset event, and 0 otherwise. -.. c:macro:: NTSYNC_IOC_KILL_OWNER +.. c:macro:: NTSYNC_IOC_MUTEX_KILL Mark a mutex as unowned and abandoned if it is owned by the given owner. Takes an input-only pointer to a 32-bit integer denoting the -- 2.53.0

July 20, 2026

[PATCH 0/4] ntsync miscellaneous patches

by Elizabeth Figura

This is a resend of a series originally submitted as [1], now sent to char-misc. The following is the original cover letter sent with that series. [1] https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/ === This series improves ntsync without changing wait/wake semantics: 1/4 — Align Documentation/userspace-api/ntsync.rst with include/uapi/linux/ntsync.h (ioctl macro names and struct layout). 2/4 — Fix wake_all selftest: CREATE_EVENT returns an fd, not zero. 3/4 — Add selftests for documented EINVAL cases (zero owner, non-zero pad, cross-instance object use). 4/4 — Reject wait ioctls when owner is zero, matching the documented uAPI (3/4 depends on 4/4 for the owner tests). Patch 4/4 closes a spec gap: Documentation/userspace-api/ntsync.rst requires EINVAL when wait owner is zero, but setup_wait() only validated pad and flags. Unlock/kill mutex ioctls already reject owner == 0. Testing: - scripts/checkpatch.pl --strict --no-tree: clean (4/4 patches) - make headers && make -C tools/testing/selftests TARGETS=drivers/ntsync - Kernel 7.1.0-ntsync-test+ (CONFIG_NTSYNC=y), QEMU x86_64 initramfs: tools/testing/selftests/drivers/ntsync/ntsync — 12/12 PASS, including wake_all and wait_args_validation - On 6.17.0-35-generic with the distro ntsync.ko (without patch 4/4): wait_args_validation fails on owner==0 (wait proceeds instead of EINVAL), confirming the gap this series fixes Iván Ezequiel Rodriguez (4): docs: ntsync: align uAPI ioctl names and struct layout with ntsync.h selftests: ntsync: fix wake_all CREATE_EVENT fd expectation selftests: ntsync: add wait argument validation tests ntsync: reject wait ioctls with zero owner Documentation/userspace-api/ntsync.rst | 22 ++++----- drivers/misc/ntsync.c | 3 ++ .../testing/selftests/drivers/ntsync/ntsync.c | 46 ++++++++++++++++++- 3 files changed, 59 insertions(+), 12 deletions(-) base-commit: 2cedf2272f1bb42471e646868ac572cc5752bd91 -- 2.53.0

July 20, 2026

Re: [PATCH] ntsync: Check for owner in setup_wait()

by Elizabeth Figura

On Tuesday, 14 July 2026 23:56:35 CDT Greg Kroah-Hartman wrote: > On Tue, Jul 14, 2026 at 12:16:47PM -0500, Elizabeth Figura wrote: > > On Tuesday, 14 July 2026 10:36:46 CDT Griffin Kroah-Hartman wrote: > > > Add a check to see if any mutex owner is 0. > > > > > > As stated in the uapi documentation , this is a failure case that was > > > not being checked under the NTSYNC_IOC_WAIT_ANY and NTSYNC_IOC_WAIT_ALL > > > cases, which state that mutexes with no owner should fail the ioctl with > > > -EINVAL. > > > > This has already been sent I'm afraid: > > > > https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/ > > Cool, but that series wasn't sent to the maintainers to get them merged, > and there's going to be a second version as it conflicts with your > previous patches, right? > > Or are you going to batch these up and send them to Arnd and me for > inclusion later on? Ah I'm sorry, I missed that those patches weren't sent to Arnd and you. I'll resend them. The previous patches are in the same situation, but I think these cover a superset of the same ground so I'll just send them alone. > And is the wine-devel list still alive? If not, we should probably drop > that from the MAINTAINERS file. It's alive, but the address moved. I forgot that this reference needed to be updated; I apologize for that. I sent a fix there as <https://lore.kernel.org/all/20260701183214.13973-1-zfigura@codeweavers.com/>. I guess that should also have been sent to you as the relevant subsystem maintainers; I failed to properly think that one through.

July 16, 2026

Re: Native arm64 macOS direction: low 4GB, x18, and layout work

by alexey.rogatkin＠gmail.com

Hi Brendan, Thanks a lot for the quick and substantive reply — this is more than I expected to learn. Good to have the x18 approach confirmed: that's exactly how I ended up solving it — my loader is linked with -Wl,-platform_version,macos,11.0,12.3 after tracing the behavior to machine_task_process_signature() in the published xnu sources. The new per-thread "x18 custom ABI" mode in macOS 26.5 with a public com.apple.security.* entitlement is great news — a durable public mechanism was exactly the piece I considered missing. I'll study <os/arch/arm64.h> and the xnu tests; looking forward to your test app and the Wine-side integration. Given that, I'll hold off pushing my current changes for now and keep running on my own tree — it already unblocks the parts I need for my project. If the situation changes — the Apple work becomes public or the x18 API lands in Wine — I'd appreciate a ping; on my side I'll be following your activity as well. Thanks again, Alexey

July 16, 2026

Re: Native arm64 macOS direction: low 4GB, x18, and layout work

by Brendan Shanks

Hi Alexey, Thanks for your enthusiasm and work on this, we have been working with Apple on these issues but unfortunately there isn’t much we can share right now. Something that is now public is the mechanism for handling x18. Apple has added a special “x18 custom ABI” mode that threads can switch into when running code that uses x18, and then switch out of when calling back into system frameworks. This was added publicly in macOS 26.5, take a look at <usr/include/os/arch/arm64.h> in a current SDK. Using this mode requires use of the com.apple.security.custom-x18-abi-toggle entitlement. I have a test app that exercises various parts of this API (which I’d like to clean up and post soon), and the xnu source tree also contains various tests around x18. I'm also working on using this API in Wine. Alternately, older versions of macOS (11/12) did not clear x18, and current versions of macOS continue to maintain that behavior for binaries built against those older SDKs. If you link with -Wl,-platform_version,macos,11.0,11.0, the kernel won’t touch x18. You’ve clearly done a lot of work on this, and I apologize I don’t have more to share. We hope that situation will change soon. Brendan > On Jul 11, 2026, at 3:30 PM, Alexey Rogatkin via Wine-Devel <wine-devel(a)list.winehq.org> wrote: > > Hi, > > I'm working on a research project around running Windows games on Apple > Silicon without Rosetta. It touches both translation layers needed for that: > DirectX-to-Metal on the graphics side, and a native macOS CPU-emulation backend > for x86-64 code in Wine. FEX already fills a similar role on ARM64 Linux, but > upstream FEX currently has no plans to support macOS: > https://github.com/FEX-Emu/FEX/discussions/3267 > > This brought me to the native arm64 macOS Wine runtime work, because that > backend needs Wine itself to run as an arm64 process. I currently have a small > local series on top of master that gets much further than stock Wine on Apple > Silicon: it fixes the host address-space limit probe with a Mach-based path, > moves Wine-owned low-address fixtures such as KUSER_SHARED_DATA and the initial > TEB block out of the mandatory 4GB __PAGEZERO, adjusts the loader flags needed > for native arm64 macOS, and handles the executable-protection issue for PE > image code. With that, native arm64 Wine boots a prefix and runs builtin PE > applications with winemac.drv. > > Then I saw Alexandre's note on my GitLab account-verification issue saying > that Wine is working with Apple on the low 4GB space and the x18 register, > hopefully avoiding Wine-side workarounds. That's exactly the area my local > patches touch, so I tried to find the current plan before going further. > > What I found publicly so far: > > - Martin Storsjo's 2020 "[PATCH 0/4] macOS/arm64" series. The build fixes were > merged, but the runtime issues described there (16KB pages, user_shared_data > relocation, W^X) don't seem to have become an upstream runtime solution. > - Recent master has useful arm64/ARM64EC groundwork, but I couldn't find > anything current for the native macOS low-4GB/x18 work. > - x18 seems to be handled differently on Linux; the Darwin side appears to be a > separate platform problem. > - I couldn't find a current branch, merge request, or wine-devel thread tracking > this. I may simply have missed it. > > My questions are: > > 1. Is the native arm64 macOS work tracked somewhere public that I should follow, > and if not, is there a good way for an outside contributor to get involved? > 2. Which parts of this area are worth preparing as Wine merge requests now, and > which are expected to be handled by Apple or by another upstream direction? > 3. For x18 specifically, is Wine aiming for a durable Apple-provided mechanism, > or should a Wine-side loader/toolchain accommodation be considered for now? > 4. Does a small shared layout contract for Wine-owned fixed low addresses sound > like a reasonable shape, or would maintainers prefer a different model? > > I'm happy to send the local series as RFC patches, split or reshaped however is > most useful. I'd much rather align with Wine's architecture than carry private > platform plumbing. > > For the record, I've worked only from public documentation, independent tests, > and public sources such as Wine, FEX-Emu, Apple's open-source XNU drops, and > Microsoft's public ARM64EC ABI documentation. I have not looked at Microsoft > Windows source code. > > Best regards, > Alexey Rogatkin

July 16, 2026

Native arm64 macOS direction: low 4GB, x18, and layout work

by Alexey Rogatkin

Hi, I'm working on a research project around running Windows games on Apple Silicon without Rosetta. It touches both translation layers needed for that: DirectX-to-Metal on the graphics side, and a native macOS CPU-emulation backend for x86-64 code in Wine. FEX already fills a similar role on ARM64 Linux, but upstream FEX currently has no plans to support macOS: https://github.com/FEX-Emu/FEX/discussions/3267 This brought me to the native arm64 macOS Wine runtime work, because that backend needs Wine itself to run as an arm64 process. I currently have a small local series on top of master that gets much further than stock Wine on Apple Silicon: it fixes the host address-space limit probe with a Mach-based path, moves Wine-owned low-address fixtures such as KUSER_SHARED_DATA and the initial TEB block out of the mandatory 4GB __PAGEZERO, adjusts the loader flags needed for native arm64 macOS, and handles the executable-protection issue for PE image code. With that, native arm64 Wine boots a prefix and runs builtin PE applications with winemac.drv. Then I saw Alexandre's note on my GitLab account-verification issue saying that Wine is working with Apple on the low 4GB space and the x18 register, hopefully avoiding Wine-side workarounds. That's exactly the area my local patches touch, so I tried to find the current plan before going further. What I found publicly so far: - Martin Storsjo's 2020 "[PATCH 0/4] macOS/arm64" series. The build fixes were merged, but the runtime issues described there (16KB pages, user_shared_data relocation, W^X) don't seem to have become an upstream runtime solution. - Recent master has useful arm64/ARM64EC groundwork, but I couldn't find anything current for the native macOS low-4GB/x18 work. - x18 seems to be handled differently on Linux; the Darwin side appears to be a separate platform problem. - I couldn't find a current branch, merge request, or wine-devel thread tracking this. I may simply have missed it. My questions are: 1. Is the native arm64 macOS work tracked somewhere public that I should follow, and if not, is there a good way for an outside contributor to get involved? 2. Which parts of this area are worth preparing as Wine merge requests now, and which are expected to be handled by Apple or by another upstream direction? 3. For x18 specifically, is Wine aiming for a durable Apple-provided mechanism, or should a Wine-side loader/toolchain accommodation be considered for now? 4. Does a small shared layout contract for Wine-owned fixed low addresses sound like a reasonable shape, or would maintainers prefer a different model? I'm happy to send the local series as RFC patches, split or reshaped however is most useful. I'd much rather align with Wine's architecture than carry private platform plumbing. For the record, I've worked only from public documentation, independent tests, and public sources such as Wine, FEX-Emu, Apple's open-source XNU drops, and Microsoft's public ARM64EC ABI documentation. I have not looked at Microsoft Windows source code. Best regards, Alexey Rogatkin

July 11, 2026