On Mon, Aug 25, 2025 at 05:27:16PM -0700, Sean Christopherson wrote: > On Mon, Aug 25, 2025, Nuno Das Neves wrote: > > On 8/25/2025 1:06 PM, Sean Christopherson wrote: > > > Fix a bug where MSHV root partitions don't honor NEED_RESCHED_LAZY, and then > > > deduplicate the TIF related MSHV code by turning the "kvm" entry APIs into > > > more generic "virt" APIs (which ideally would have been done when MSHV root > > > support was added). > > > > > > Assuming all is well, maybe this could go through the tip tree? > > > > > > The Hyper-V stuff and non-x86 architectures are compile-tested only. > > > > > > > Thanks Sean, I can test the root partition changes. > > > > A similar change will be needed in mshv_vtl_main.c since it also calls > > mshv_do_pre_guest_mode_work() (hence the "common" in mshv_common.c). > > Oof, more dependencies. I suppose the easiest thing would be to send a series > against > > git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git queue > > and then route everything through there? Our fixes branch is on 6.17-rc1. You can use it as a base if you want to. > > Alternatively, frontload the MSHV fixes (which I'll do regardless) and take those > through hyperv and the rest through the tip tree? That seems like an absurd > amount of juggling though, especially if we want to get the cleanups into 6.18. > And if none of these lands, it's MSHV that'll suffer the most, so betting it all > on the hyperv tree doesn't seem terrible. > I'm happy to do it however the community sees fit. > > Also, is it possible to make all the mshv driver changes in a single patch? > > It's certainly possible, but I'd prefer not do to that. > > > It seems like it would be cleaner than refactoring it in patches 1 & 2 and > > then deleting all the refactored code in patch 5. > > Only if you don't care about backporting fixes, bisection, or maintaining code. > > E.g. if checking NEED_RESCHED_LAZY somehow causes issues, it would be really nice > for that to bisect to exactly that patch, not a patch that also switches to a > completely different set of APIs. > > And if someone is wants the fixes in a pre-6.18 kernel, they don't need to > backport all of the KVM and entry code changes just to get the fix. +1 on this. Thanks, Wei > > As for the maintenance headache, see above.
