linux-rng/drivers/hv, branch master

Merge tag 'core-rseq-2025-11-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2025-12-02T16:48:53Z

Pull rseq updates from Thomas Gleixner: "A large overhaul of the restartable sequences and CID management: The recent enablement of RSEQ in glibc resulted in regressions which are caused by the related overhead. It turned out that the decision to invoke the exit to user work was not really a decision. More or less each context switch caused that. There is a long list of small issues which sums up nicely and results in a 3-4% regression in I/O benchmarks. The other detail which caused issues due to extra work in context switch and task migration is the CID (memory context ID) management. It also requires to use a task work to consolidate the CID space, which is executed in the context of an arbitrary task and results in sporadic uncontrolled exit latencies. The rewrite addresses this by: - Removing deprecated and long unsupported functionality - Moving the related data into dedicated data structures which are optimized for fast path processing. - Caching values so actual decisions can be made - Replacing the current implementation with a optimized inlined variant. - Separating fast and slow path for architectures which use the generic entry code, so that only fault and error handling goes into the TIF_NOTIFY_RESUME handler. - Rewriting the CID management so that it becomes mostly invisible in the context switch path. That moves the work of switching modes into the fork/exit path, which is a reasonable tradeoff. That work is only required when a process creates more threads than the cpuset it is allowed to run on or when enough threads exit after that. An artificial thread pool benchmarks which triggers this did not degrade, it actually improved significantly. The main effect in migration heavy scenarios is that runqueue lock held time and therefore contention goes down significantly" * tag 'core-rseq-2025-11-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (54 commits) sched/mmcid: Switch over to the new mechanism sched/mmcid: Implement deferred mode change irqwork: Move data struct to a types header sched/mmcid: Provide CID ownership mode fixup functions sched/mmcid: Provide new scheduler CID mechanism sched/mmcid: Introduce per task/CPU ownership infrastructure sched/mmcid: Serialize sched_mm_cid_fork()/exit() with a mutex sched/mmcid: Provide precomputed maximal value sched/mmcid: Move initialization out of line signal: Move MMCID exit out of sighand lock sched/mmcid: Convert mm CID mask to a bitmap cpumask: Cache num_possible_cpus() sched/mmcid: Use cpumask_weighted_or() cpumask: Introduce cpumask_weighted_or() sched/mmcid: Prevent pointless work in mm_update_cpus_allowed() sched/mmcid: Move scheduler code out of global header sched: Fixup whitespace damage sched/mmcid: Cacheline align MM CID storage sched/mmcid: Use proper data structures sched/mmcid: Revert the complex CID management ...

hv: convert mshv_ioctl_create_partition() to FD_ADD()

2025-11-28T11:42:35Z

Link: https://patch.msgid.link/20251123-work-fd-prepare-v4-39-b6efa1706cfd@kernel.org Signed-off-by: Christian Brauner

rseq, virt: Retrigger RSEQ after vcpu_run()

2025-11-04T07:30:23Z

Hypervisors invoke resume_user_mode_work() before entering the guest, which clears TIF_NOTIFY_RESUME. The @regs argument is NULL as there is no user space context available to them, so the rseq notify handler skips inspecting the critical section, but updates the CPU/MM CID values unconditionally so that the eventual pending rseq event is not lost on the way to user space. This is a pointless exercise as the task might be rescheduled before actually returning to user space and it creates unnecessary work in the vcpu_run() loops. It's way more efficient to ignore that invocation based on @regs == NULL and let the hypervisors re-raise TIF_NOTIFY_RESUME after returning from the vcpu_run() loop before returning from the ioctl(). This ensures that a pending RSEQ update is not lost and the IDs are updated before returning to user space. Once the RSEQ handling is decoupled from TIF_NOTIFY_RESUME, this turns into a NOOP. Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Mathieu Desnoyers Acked-by: Sean Christopherson Link: https://patch.msgid.link/20251027084306.399495855@linutronix.de

Drivers: hv: Make CONFIG_HYPERV bool

2025-10-01T00:00:45Z

With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V hypervisor support, such as hypercalls, clocks/timers, Confidential Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus devices. Signed-off-by: Mukesh Rathor Signed-off-by: Wei Liu

Drivers: hv: Add CONFIG_HYPERV_VMBUS option

2025-10-01T00:00:42Z

At present VMBus driver is hinged off of CONFIG_HYPERV which entails lot of builtin code and encompasses too much. It's not always clear what depends on builtin hv code and what depends on VMBus. Setting CONFIG_HYPERV as a module and fudging the Makefile to switch to builtin adds even more confusion. VMBus is an independent module and should have its own config option. Also, there are scenarios like baremetal dom0/root where support is built in with CONFIG_HYPERV but without VMBus. Lastly, there are more features coming down that use CONFIG_HYPERV and add more dependencies on it. So, create a fine grained HYPERV_VMBUS option and update Kconfigs for dependency on VMBus. Signed-off-by: Mukesh Rathor Acked-by: Bjorn Helgaas # drivers/pci Signed-off-by: Wei Liu

Drivers: hv: vmbus: Fix typos in vmbus_drv.c

2025-09-30T23:31:00Z

Fix two minor typos in vmbus_drv.c: - Correct "reponsible" -> "responsible" in a comment. - Add missing newline in pr_err() message ("channeln" -> "channel\n"). These are cosmetic changes only and do not affect functionality. Signed-off-by: Alok Tiwari Reviewed-by: Michael Kelley Signed-off-by: Wei Liu

Drivers: hv: vmbus: Fix sysfs output format for ring buffer index

2025-09-30T23:31:00Z

The sysfs attributes out_read_index and out_write_index in vmbus_drv.c currently use %d to print outbound.current_read_index and outbound.current_write_index. These fields are u32 values, so printing them with %d (signed) is not logically correct. Update the format specifier to %u to correctly match their type. No functional change, only fixes the sysfs output format. Signed-off-by: Alok Tiwari Reviewed-by: Michael Kelley Signed-off-by: Wei Liu

Drivers: hv: vmbus: Clean up sscanf format specifier in target_cpu_store()

2025-09-30T23:30:56Z

The target_cpu_store() function parses the target CPU from the sysfs buffer using sscanf(). The format string currently uses "%uu", which is redundant. The compiler ignores the extra "u", so there is no incorrect parsing at runtime. Update the format string to use "%u" for clarity and consistency. Signed-off-by: Alok Tiwari Reviewed-by: Michael Kelley Signed-off-by: Wei Liu

x86/hyperv: Switch to msi_create_parent_irq_domain()

2025-09-30T22:50:48Z

Move away from the legacy MSI domain setup, switch to use msi_create_parent_irq_domain(). While doing the conversion, I noticed that hv_irq_compose_msi_msg() is doing more than it is supposed to (composing message content). The interrupt allocation bits should be moved into hv_msi_domain_alloc(). However, I have no hardware to test this change, therefore I leave a TODO note. Signed-off-by: Nam Cao Acked-by: Thomas Gleixner Tested-by: Nuno Das Neves Reviewed-by: Nuno Das Neves Signed-off-by: Wei Liu

mshv: Use common "entry virt" APIs to do work in root before running guest

2025-09-30T22:50:48Z

Use the kernel's common "entry virt" APIs to handle pending work prior to (re)entering guest mode, now that the virt APIs don't have a superfluous dependency on KVM. No functional change intended. Signed-off-by: Sean Christopherson Tested-by: Nuno Das Neves Reviewed-by: Nuno Das Neves Signed-off-by: Wei Liu