[PATCH 11/13] arch, mm: streamline HIGHMEM freeing

2025-03-15 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" All architectures that support HIGHMEM have their code that frees high memory pages to the buddy allocator while __free_memory_core() is limited to freeing only low memory. There is no actual reason for that. The memory map is completely ready by the time memblo

[PATCH 09/13] arch, mm: set max_mapnr when allocating memory map for FLATMEM

2025-03-15 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" max_mapnr is essentially the size of the memory map for systems that use FLATMEM. There is no reason to calculate it in each and every architecture when it's anyway calculated in alloc_node_mem_map(). Drop setting of max_mapnr from architecture code and set it o

[PATCH 0/3] um: Add VFIO-based PCI passthrough support

2025-03-15 Thread Tiwei Bie
This patchset adds a new virt-pci driver to UML that allows users to pass through host PCI devices to UML via VFIO. Currently, only MSI-X capable devices are supported, and drivers are assumed to use MSI-X. This driver has been tested with virtio-net-pci, virtio-blk-pci and nvme in a QEMU virtual

[PATCH 2/3] um: virt-pci: Refactor virtio_pcidev into its own module

2025-03-15 Thread Tiwei Bie
Decouple virt-pci and virtio_pcidev, refactoring virtio_pcidev into its own module. Define a set of APIs for virt-pci. This allows for future addition of more PCI emulation implementations. Signed-off-by: Tiwei Bie --- arch/um/drivers/Kconfig | 12 +- arch/um/drivers/Makefile|

[PATCH 3/3] um: Add VFIO-based virtual PCI driver

2025-03-15 Thread Tiwei Bie
Implement a new virtual PCI driver based on the VFIO framework. This driver allows users to pass through PCI devices to UML via VFIO. Currently, only MSI-X capable devices are supported, and it is assumed that drivers will use MSI-X. Signed-off-by: Tiwei Bie --- arch/um/drivers/Kconfig | 8

[PATCH 1/3] um: Rewrite the sigio workaround based on epoll and tgkill

2025-03-15 Thread Tiwei Bie
The existing sigio workaround implementation removes FDs from the poll when events are triggered, requiring users to re-add them via add_sigio_fd() after processing. This introduces a potential race condition between FD removal in write_sigio_thread() and next_poll update in __add_sigio_fd(), and i

[PATCH] um: work around sched_yield not yielding in time-travel mode

2025-03-15 Thread Benjamin Berg
From: Benjamin Berg sched_yield by a userspace may not actually cause scheduling in time-travel mode as no time has passed. In the case seen it appears to be a badly implemented userspace spinlock in ASAN. Unfortunately, with time-travel it causes an extreme slowdown or even deadlock depending on