wine-devel

wine-devel@winehq.org

84463 discussions

Re: [RFC PATCH 0/9] NT synchronization primitive driver
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 18:59:35 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:19PM -0600, Elizabeth Figura wrote: > > == Patches == > > > > This is the first part of a 32-patch series. The series comprises 17 patches > > which contain the actual implementation, 13 which provide self-tests, 1 to > > update the MAINTAINERS file, and 1 to add API documentation. > > 32 patches? I only see 9 here, why not submit them all? Because Documentation/process/submitting-patches.rst makes a point of asking people not to submit large patch series (and it matches the expectation of other projects I've worked with—that patches would be submitted and reviewed a few at a time). I suppose I've misunderstood that advice, though. I'll resend with the entire series. Sorry for the noise.

1 0

9.0 release notes, please review
by Alexandre Julliard 18 Jan '24

18 Jan '24

Folks, We've once again made very good progress on the regressions during this code freeze period, thanks to everybody for your help! It's now time for the final release. I've attached the tentative release notes, written with help from Jacek, Rémi and Zeb, and for the first time in Markdown format <g>. Please review these and let me know if anything is wrong, missing, or unclear. -- Alexandre Julliard julliard(a)winehq.org

8 17

Force feedback auto center implementation?
by Tyson Whitehead 13 Jan '24

13 Jan '24

Would like to get disabling force feedback auto-centering working so that trimming will work properly with force feedback devices in flight simulators. Currently the call to disable it is a stub static HRESULT dinput_device_set_property( IDirectInputDevice8W *iface, const GUID *guid, const DIPROPHEADER *header ) { ... case (DWORD_PTR)DIPROP_AUTOCENTER: { const DIPROPDWORD *value = (const DIPROPDWORD *)header; if (!(impl->caps.dwFlags & DIDC_FORCEFEEDBACK)) return DIERR_UNSUPPORTED; if ( header->dwHow != DIPH_DEVICE) return DIERR_INVALIDPARAM; impl->vtbl->set_property( iface, FIXME( "DIPROP_AUTOCENTER stub!\n" ); impl->autocenter = value->dwData; return DI_OK; } ... } After having looked through the wine, SDL, and kernel code and read up on the force feedback HID physical interface device (PID) usage table reports, I am guessing this was left as a stub because it doesn't fit in with the current design of dipnut communicating with the backend via HID reports. The issue being that auto centering, unlike everything else, isn't part of the PID specification, so there isn't a predefined report that can be used for this (see table 0x0f) https://www.usb.org/document-library/hid-usage-tables-14 Although I am no wine or Windows code expert, I am guess this leaves the following options - leave it disabled in the backend and emulate it via a frontend spring effect - abuse an existing HID report to communicate it - add a WINE specific HID report to communicate it - add a WINE specific IOCTL to communicate it For the first option, I mean have the winebus backends disable it via the kernel or an SDL call and then have the dinput layer enable simulate it by adding a default spring effect. This then lets the dinput frontend disable it again by removing or disabling its spring effect. For the second one I mean something like reserve an effect ID for specifying auto centering. Both of these are inspired by the fact that from the kernel code, it seems auto centering for HID devices is an undocumented use of the first effect ID for a spring effect https://github.com/torvalds/linux/blob/610a9b8f/drivers/hid/usbhid/hid-pidf… https://github.com/torvalds/linux/blob/610a9b8f/drivers/hid/usbhid/hid-pidf… Would be interesting in knowing what sort of implementation people think would be best and acceptable for inclusion into wine? Thanks! Tyson

2 8

Wine staging 9.0-rc5 release
by Alistair Leslie-Hughes 13 Jan '24

13 Jan '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc5 (500 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

vkd3d request
by Alistair Leslie-Hughes 09 Jan '24

09 Jan '24

Hi All, Now that vkd3d 1.10 is out, I have a request for developers. Would it be possible to include a file of all games/applications that have fixes when they are committed. It's too hard to track unless you really doing serious work with it. The whole concept of including the latest vk3d3d in staging was to help with testing but if people don't know what to test, they wont. This would also, give a nice section in the ANNOUNCE as to what now works. :) Best Regards Alistair

3 4

[PATCH] po: Update Asturian translation
by Enol P. 08 Jan '24

08 Jan '24

2 2

Wine staging 9.0-rc4 release
by Alistair Leslie-Hughes 06 Jan '24

06 Jan '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc4 (500 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

Re: x86 SGDT emulation for Wine
by H. Peter Anvin 05 Jan '24

05 Jan '24

On January 4, 2024 6:47:04 PM PST, Andrew Cooper <andrew.cooper3(a)citrix.com> wrote: >On 05/01/2024 1:02 am, H. Peter Anvin wrote: >> Note that there is no fundamental reason you cannot run the Unix user space code inside the VM container, too; you only need to vmexit on an actual system call. > >I know this is going on a tangent, but getting a VMExit on the SYSCALL >instruction is surprisingly difficult. > >The "easy" way is to hide EFER.SCE behind the guests back, intercept #UD >and emulate both the SYSCALL and SYSRET instructions. It's slow, but it >works. > >However, FRED completely prohibits tricks like this, because what you >cannot reasonably do is clear CR4.FRED behind the back of a guest >kernel. You'd have to intercept and emulate all event sources in order >to catch SYSCALL. > >I raised this as a concern during early review, but Intel has no >official feature to take a VMExit on privilege change, and FRED >(rightly) wasn't an appropriate vehicle to add such a feature, so it was >deemed not an issue that the FRED design would break the unofficial ways >that people were using to intercept/monitor/etc system calls. > >~Andrew > >P.S. Yes, there are more adventurous tricks like injecting a thunk into >the guest kernel and editing MSR_LSTAR behind the guest's back. In >principle a similar trick works with FRED, but in order to do this to >Windows, you also need to hook checkpatch to blind it to the thunk, and >this is horribly invasive. *In this case* it shouldn't be a problem, since the "guest operating system" would be virtually nonexistent and entirely puppeted by Wine.

1 0

Re: x86 SGDT emulation for Wine
by H. Peter Anvin 05 Jan '24

05 Jan '24

On January 3, 2024 7:19:02 AM PST, Sean Christopherson <seanjc(a)google.com> wrote: >On Tue, Jan 02, 2024, Elizabeth Figura wrote: >> On Wednesday, December 27, 2023 5:58:19 PM CST H. Peter Anvin wrote: >> > On December 27, 2023 2:20:37 PM PST, Elizabeth Figura <zfigura(a)codeweavers.com> wrote: >> > >Hello all, >> > > >> > >There is a Windows 98 program, a game called Nuclear Strike, which wants to >> > >do some amount of direct VGA access. Part of this is port I/O, which >> > >naturally throws SIGILL that we can trivially catch and emulate in Wine. >> > >The other part is direct access to the video memory at 0xa0000, which in >> > >general isn't a problem to catch and virtualize as well. >> > > >> > >However, this program is a bit creative about how it accesses that memory; >> > >instead of just writing to 0xa0000 directly, it looks up a segment >> > >descriptor whose base is at 0xa0000 and then uses the %es override to >> > >write bytes. In pseudo-C, what it does is: > >... > >> > A prctl() to set the UMIP-emulated return values or disable it (giving >> > SIGILL) would be easy enough. >> > >> > For the non-UMIP case, and probably for a lot of other corner cases like >> > relying on certain magic selector values and what not, the best option >> > really would be to wrap the code in a lightweight KVM container. I do *not* >> > mean running the Qemu user space part of KVM; instead have Wine interface >> > with /dev/kvm directly. >> > >> > Non-KVM-capable hardware is basically historic at this point. >> >> Sorry for the late response—I've been trying to do research on what would be >> necessary to use KVM (plus I made the poor choice of sending this during the >> holiday season...) >> >> I'm concerned that KVM is going to be difficult or even intractable. Here are >> some of the problems that I (perhaps incorrectly) understand: >> >> * As I am led to understand, there can only be one hypervisor on the machine >> at a time, > >No. Only one instance of KVM-the-module is allowed, but there is no arbitrary >limit on the number of VMs that userspace can create. The only meaningful >limitation is memory, and while struct kvm isn't tiny, it's not _that_ big. > >> and KVM has a hard limit on the number of vCPUs. >> >> The obvious way to use KVM for Wine is to make each (guest) thread a vCPU. >> That will, at the very least, run into the thread limit. In order to avoid >> that we'd need to ship a whole scheduler, which is concerning. That's a huge >> component to ship and a huge burden to keep updated. It also means we need to >> hoist *all* of the ipc and sync code into the guest, which will take an >> enormous amount of work. >> >> Moreover, because there can only be one hypervisor, and Wine is a multi- >> process beast, that means that we suddenly need to throw every process into >> the same VM. > >As above, this is wildly inaccurate. The only KVM restriction with respect to >processes is that a VM is bound to the process (address space) that created the >VM. There are no restrictions on the number of VMs that can be created, e.g. a >single process can create multiple VMs. > >> That has unfortunate implications regarding isolation (it's been a dream for >> years that we'd be able to share a single wine "VM" between multiple users), >> it complicates memory management (though perhaps not terribly?). And it means >> you can only have one Wine VM at a time, and can't use Wine at the same time >> as a "real" VM, neither of which are restrictions that currently exist. >> >> And it's not even like we can refactor—we'd have to rewrite tons of code to >> work inside a VM, but also keep the old code around for the cases where we >> don't have a VM and want to delegate scheduling to the host OS. >> >> * Besides scheduling, we need to exit the VM every time we would normally call >> into Unix code, which in practice is every time that the application does an >> NT syscall, or uses a library which we delegate to the host (including e.g. >> GPU, multimedia, audio...) > >Maybe I misinterpreted Peter's suggestion, but at least in my mind I wasn't thinking >that the entire Wine process would run in a VM, but rather Wine would run just >the "problematic" code in a VM. > Yes, the idea would be that you would run the "problematic" code inside a VM *mapped 1:1 with the external address space*, i.e. use KVM simply as a special execution mode to give you more control of the fine grained machine state like the GDT. The code that you don't want executed in the VM context simply leave unmapped in the VM page tables and set up #PF to always exit the VM context.

2 2

x86 SGDT emulation for Wine
by Elizabeth Figura 03 Jan '24

03 Jan '24

Hello all, There is a Windows 98 program, a game called Nuclear Strike, which wants to do some amount of direct VGA access. Part of this is port I/O, which naturally throws SIGILL that we can trivially catch and emulate in Wine. The other part is direct access to the video memory at 0xa0000, which in general isn't a problem to catch and virtualize as well. However, this program is a bit creative about how it accesses that memory; instead of just writing to 0xa0000 directly, it looks up a segment descriptor whose base is at 0xa0000 and then uses the %es override to write bytes. In pseudo-C, what it does is: int get_vga_selector() { sgdt(&gdt_size, &gdt_ptr); sldt(&ldt_segment); ++gdt_size; descriptor = gdt_ptr; while (descriptor->base != 0xa0000) { ++descriptor; gdt_size -= sizeof(*descriptor); if (!gdt_size) break; } if (gdt_size) return (descriptor - gdt_ptr) << 3; descriptor = gdt_ptr[ldt_segment >> 3]->base; ldt_size = gdt_ptr[ldt_segment >> 3]->limit + 1; while (descriptor->base != 0xa0000) { ++descriptor; ldt_size -= sizeof(*descriptor); if (!ldt_size) break; } if (ldt_size) return (descriptor - ldt_ptr) << 3; return 0; } Currently we emulate IDT access. On a read fault, we execute sidt ourselves, check if the read address falls within the IDT, and return some dummy data from the exception handler if it does [1]. We can easily enough implement GDT access as well this way, and there is even an out-of-tree patch written some years ago that does this, and helps the game run. However, there are two problems that I have observed or anticipated: (1) On systems with UMIP, the kernel emulates sgdt instructions and returns a consistent address which we can guarantee is invalid. However, it also returns a size of zero. The program doesn't expect this (cf. the way the loop is written above) and I believe will effectively loop forever in that case, or until it finds the VGA selector or hits invalid memory. I see two obvious ways to fix this: either adjust the size of the fake kernel GDT, or provide a switch to stop emulating and let Wine handle it. The latter may very well a more sustainable option in the long term (although I'll admit I can't immediately come up with a reason why, other than "we might need to raise the size yet again".) Does anyone have opinions on this particular topic? I can look into writing a patch but I'm not sure what the best approach is. (2) On 64-bit systems without UMIP, sgdt returns a truncated address when in 32-bit mode. This truncated address in practice might point anywhere in the address space, including to valid memory. In order to fix this, we would need the kernel to guarantee that the GDT base points to an address whose bottom 32 bits we can guarantee are inaccessible. This is relatively easy to achieve ourselves by simply mapping those pages as noaccess, but it also means that those pages can't overlap something we need; we already go to pains to make sure that certain parts of the address space are free. Broadly anything above the 2G boundary *should* be okay though. Is this feasible? We could also just decide we don't care about systems without UMIP, but that seems a bit unfortunate; it's not that old of a feature. But I also have no idea how hard it would be to make this kind of a guarantee on the kernel side. This is also, theoretically, a problem for the IDT, except that on the machines I've tested, the IDT is always at 0xfffffe0000000000. That's not great either (it's certainly caused some weirdness and confusion when debugging, when we unexpectedly catch an unrelated null pointer access) but it seems to work in practice. --Zeb [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/ instr.c#l702

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel