This MR adds support for creating file mapping objects backed by large pages on Linux, by making the following changes:
## wineserver
* On Linux, `create_temp_file` will first attempt to use memfds as the backing fd. If it fails, it'll return to the current codepath, creating a temporary file in either the server or config directory.
* The created memfd will be sealed against writes, if the caller requesting the appropriate page protection flags.
* This removes the requirement that FDs be only created on filesystems/directories that aren't `noexec`.
* In the server method `create_mapping` , if large pages have been requested by the caller, hold that the calling thread's token holds `SeLockMemoryPrivilege` .
* Additionally, add `SeLockMemoryPrivilege` to the list of privileges enabled for the Administrator.
## `ntdll`
* Add `virtual_get_min_large_page_size` and its exported wrapper `wine_unix_get_min_large_page_size`.
* On Linux, the minimum page size is determined by going through `/sys/kernel/mm/hugepages`. If hugepage support was not detected, `STATUS_NOT_SUPPORTED` is returned instead. On other platforms, the older hard-coded value of 2\*1024\*1024 is returned instead.
* `NtCreateSection` will validate certain parameters if large pages are requested. Specifically, it will return STATUS_INVALID_PARAMETER if the requested mapping is not anonymous/unnamed, or the size is not a multiple of the minimum supported page size.
## `kernelbase`
* `GetLargePageMinimum` will use `wine_unix_get_min_large_page_size`.
## `kernel32/tests`
* Add new test test_large_page_file_mapping, which validates privilege enforcements and parameter validation while creating large pages backed file mapping obejcts. The tests are skipped if `GetLargePageMinimum` returns 0.
--
v31: psapi: Add tests for querying information for large pages.
ntdll: Use PAGEMAP_SCAN ioctl to implement get_working_set_ex, if available.
kernel32: Add tests for large pages support.
ntdll: Support allocating virtual memory, creating and mapping files backed by large/huge pages.
server: Use memfd to back anonymous mappings on Linux.
kernelbase: Implement GetLargePageMinimum by returning the value of LargePageMinimum in _KUSER_SHARED_DATA.
server: Set LargePageMinimum in _KUSER_SHARED_DATA on Linux.
server: Require SeLockMemoryPrivilege to create large page mappings.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769
This MR adds support for creating file mapping objects backed by large pages on Linux, by making the following changes:
## wineserver
* On Linux, `create_temp_file` will first attempt to use memfds as the backing fd. If it fails, it'll return to the current codepath, creating a temporary file in either the server or config directory.
* The created memfd will be sealed against writes, if the caller requesting the appropriate page protection flags.
* This removes the requirement that FDs be only created on filesystems/directories that aren't `noexec`.
* In the server method `create_mapping` , if large pages have been requested by the caller, hold that the calling thread's token holds `SeLockMemoryPrivilege` .
* Additionally, add `SeLockMemoryPrivilege` to the list of privileges enabled for the Administrator.
## `ntdll`
* Add `virtual_get_min_large_page_size` and its exported wrapper `wine_unix_get_min_large_page_size`.
* On Linux, the minimum page size is determined by going through `/sys/kernel/mm/hugepages`. If hugepage support was not detected, `STATUS_NOT_SUPPORTED` is returned instead. On other platforms, the older hard-coded value of 2\*1024\*1024 is returned instead.
* `NtCreateSection` will validate certain parameters if large pages are requested. Specifically, it will return STATUS_INVALID_PARAMETER if the requested mapping is not anonymous/unnamed, or the size is not a multiple of the minimum supported page size.
## `kernelbase`
* `GetLargePageMinimum` will use `wine_unix_get_min_large_page_size`.
## `kernel32/tests`
* Add new test test_large_page_file_mapping, which validates privilege enforcements and parameter validation while creating large pages backed file mapping obejcts. The tests are skipped if `GetLargePageMinimum` returns 0.
--
v30: psapi: Add tests for querying information for large pages.
ntdll: Use PAGEMAP_SCAN ioctl to implement get_working_set_ex, if available.
kernel32: Add tests for large pages support.
ntdll: Support allocating virtual memory, creating and mapping files backed by large/huge pages.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769
This MR adds support for creating file mapping objects backed by large pages on Linux, by making the following changes:
## wineserver
* On Linux, `create_temp_file` will first attempt to use memfds as the backing fd. If it fails, it'll return to the current codepath, creating a temporary file in either the server or config directory.
* The created memfd will be sealed against writes, if the caller requesting the appropriate page protection flags.
* This removes the requirement that FDs be only created on filesystems/directories that aren't `noexec`.
* In the server method `create_mapping` , if large pages have been requested by the caller, hold that the calling thread's token holds `SeLockMemoryPrivilege` .
* Additionally, add `SeLockMemoryPrivilege` to the list of privileges enabled for the Administrator.
## `ntdll`
* Add `virtual_get_min_large_page_size` and its exported wrapper `wine_unix_get_min_large_page_size`.
* On Linux, the minimum page size is determined by going through `/sys/kernel/mm/hugepages`. If hugepage support was not detected, `STATUS_NOT_SUPPORTED` is returned instead. On other platforms, the older hard-coded value of 2\*1024\*1024 is returned instead.
* `NtCreateSection` will validate certain parameters if large pages are requested. Specifically, it will return STATUS_INVALID_PARAMETER if the requested mapping is not anonymous/unnamed, or the size is not a multiple of the minimum supported page size.
## `kernelbase`
* `GetLargePageMinimum` will use `wine_unix_get_min_large_page_size`.
## `kernel32/tests`
* Add new test test_large_page_file_mapping, which validates privilege enforcements and parameter validation while creating large pages backed file mapping obejcts. The tests are skipped if `GetLargePageMinimum` returns 0.
--
v29: psapi: Add tests for querying information for large pages.
ntdll: Use PAGEMAP_SCAN ioctl to implement get_working_set_ex, if available.
kernel32: Add tests for large pages support.
ntdll: Support allocating virtual memory, creating and mapping files backed by large/huge pages.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769
--
v2: winex11: Remove now unnecessary window surface BITMAPINFO.
winewayland: Remove now unnecessary window surface BITMAPINFO.
wineandroid: Remove now unnecessary window surface BITMAPINFO.
winemac: Remove now unnecessary driver surface BITMAPINFO.
win32u: Get rid of the unnecessary offscreen window surface struct.
win32u: Introduce a new helper to get surface color info and bits.
win32u: Pass BITMAPINFO and color bits to window surface flush.
win32u: Introduce a new helper to update layered window surface attributes.
win32u: Move layered surface attributes to the window_surface struct.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5947
This part XII of cmd engine rewrite.
This serie implements proper support for && and || command chaining operators:
- implement proper precedence parsing
- implement semantics for the operators
- for this to work, we need to have expected success/failure from commands;
this is supported here for external commands (and calling into a label or
another BAT/CMD file), but support has to be added for all builtin
commands
- that's a big mess as behaviors is far from homogeneous among the builtins:
+ some builtin set coherent success/failure vs errorlevel information
+ some report success/failure, but only set errorlevel upon failure
(keeping errorlevel from previous commands untouched),
+ some even report success (even in case of failure) yet set errorlevel
in case of failure,
- so the next series will now concentrate on testing success/failure and
errorlevel for every builtin command (sigh)
- for now, to help the transition phase, we can distinguish if a builtin
properly reports success/failure; if a builtin with success/failure
ability is used in a chaining operator, we implement the intented
behavior of the chaining operator; otherwise,
we keep old behavior (ie always execute LHS and RHS whatever the
success/failure status).
This shall be removed when all builtin commands report success/failure.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5949