Re: [PATCH v2 00/13] x86/msr: Drop 32-bit MSR interfaces
Sean Christopherson <[email protected]>
| Newsgroups | gmane.linux.kernel.cryptoapi,gmane.linux.kernel,gmane.linux.ide,gmane.comp.video.dri.devel,gmane.linux.kernel.gpio,gmane.linux.kernel.perf.user,gmane.comp.emulators.kvm.devel,gmane.linux.kernel.pci,gmane.linux.power-management.general,gmane.linux.acpi.devel,gmane.linux.kernel.hwmon,gmane.linux.drivers.mtd,gmane.linux.drivers.platform.x86.devel,gmane.linux.ports.geode,gmane.comp.emulators.xen.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Aug 19, 2026, Dave Hansen wrote: > Hey Juergen, > > These look great. Thanks for doing it! > > The only wonky thing is how we're going to actually merge it. We > obviously can't do patches 10-11 until all the "stop using" patches have > been applied. > > I obviously 100% realize that it's during the merge window, but any acks > that the maintainers of 5-9 provide in the next few weeks would be super > helpful. Or, if any of those maintainers want to cherry pick their > subsystem's stuff out of this series and apply it, that would be great too. > > But, the last time we did some MSR function munging, the tip tree > carried most of the patches. I would expect we'll have a repeat of that > here too. I'll pencil in the idea of just merging the lot around -rc1 time. Note, patch 12 "treewide: convert rdmsrq() from a macro to an inline function" is going to conflict with the KVM changes for 7.3; kvm_access_xstate_msr() is getting moved from x86.c to msrs.c. Somewhat surprisingly, AFAICT that's the only conflict with KVM's code movement, so it's probably not strictly required to send a new version after the KVM pull request?