On Tue, Sep 02, 2025 at 04:24:33PM +0000, Teddy Astie wrote: > Le 02/09/2025 à 13:18, Greg Kroah-Hartman a écrit : > > On Tue, Sep 02, 2025 at 09:28:32AM +0000, Teddy Astie wrote: > >> From: Juergen Gross <jgr...@suse.com> > >> > >> From: Juergen Gross <jgr...@suse.com> > >> > >> [ upstream commit 41925b105e345ebc84cedb64f59d20cb14a62613 ] > >> > >> xen_remap() is used to establish mappings for frames not under direct > >> control of the kernel: for Xenstore and console ring pages, and for > >> grant pages of non-PV guests. > >> > >> Today xen_remap() is defined to use ioremap() on x86 (doing uncached > >> mappings), and ioremap_cache() on Arm (doing cached mappings). > >> > >> Uncached mappings for those use cases are bad for performance, so they > >> should be avoided if possible. As all use cases of xen_remap() don't > >> require uncached mappings (the mapped area is always physical RAM), > >> a mapping using the standard WB cache mode is fine. > >> > >> As sparse is flagging some of the xen_remap() use cases to be not > >> appropriate for iomem(), as the result is not annotated with the > >> __iomem modifier, eliminate xen_remap() completely and replace all > >> use cases with memremap() specifying the MEMREMAP_WB caching mode. > >> > >> xen_unmap() can be replaced with memunmap(). > >> > >> Reported-by: kernel test robot <l...@intel.com> > >> Signed-off-by: Juergen Gross <jgr...@suse.com> > >> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> > >> Acked-by: Stefano Stabellini <sstabell...@kernel.org> > >> Link: https://lore.kernel.org/r/20220530082634.6339-1-jgr...@suse.com > >> Signed-off-by: Juergen Gross <jgr...@suse.com> > >> Signed-off-by: Teddy Astie <teddy.as...@vates.tech> [backport to 5.10.y] > >> --- > > > > Why is this needed for 5.10.y at all? What bug does it fix? And why > > are you still using Xen on a 5.10.y kernel? What prevents you from > > moving to a newer one? > > > > This patch is only useful for virtual machines (DomU) that runs this > Linux version (a notable Linux distribution with this kernel branch is > Debian 11); it's not useful for Dom0 kernels. > > On AMD platforms (and future Intel ones with TME); this patch along with > [1] makes the caching attribute for access as WB instead of falling back > to UC due to ioremap (within xen_remap) being used improving the > performance as explained in the commit.
So this is only a performance improvement? One that people have not noticed in over 3 years? That does not feel like a real bugfix that stable kernels should have to me. Again, what is preventing you from just running 5.15.y in your system instead? Debian 11 is quite old as well, why not use Debian 13 or 12? You only have one more year left of 5.10.y kernels so you need to consider moving off of that as soon as possible. thanks, greg k-h
