On Wed, May 19, 2021 at 10:03 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, May 19, 2021 at 09:42:42AM -0700, Jianxiong Gao wrote: > > On Wed, May 19, 2021 at 1:11 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > I still fail to understand why you can not just use the 5.10.y kernel or > > > newer. What is preventing you from doing this if you wish to use this > > > type of hardware? This is not a "regression" in that the 5.4.y kernel > > > has never worked with this hardware before, it feels like a new feature. > > > > > NVMe + SWIOTLB is not a new feature. From my understanding it should > > be supported by 5.4.y kernel correctly. Currently without the patch, any > > NVMe device (along with some other devices that relies on offset to > > work correctly), could be broken if the SWIOTLB is used on a 5.4.y kernel. > > Then do not do that, as obviously it never worked without your fixes, so > this isn't a "regression". NVMe + SWIOTLB works fine without this bug fix. By fine I mean that a guest kernel using this configuration boots and runs stably for weeks and months under general-purpose usage. The bug that this patch set fixes was only encountered when a user tried to format an xfs filesystem under a RHEL guest kernel. > And again, why can you not just use 5.10.y? For our use case, this fixes the guest kernel, not the host kernel. The guest distros that we support use 5.4 kernels. We do not control the kernel that the distros deploy for usage as a guest OS on cloud. We only control the host kernel. Thanks, Marc
