On Sun, 8 Jan 2023 17:44:21 +0200 Yishai Hadas <yishaih@xxxxxxxxxx> wrote: > This series changes the vfio and its sub drivers to use > GFP_KERNEL_ACCOUNT for userspace persistent allocations. > > The GFP_KERNEL_ACCOUNT option lets the memory allocator know that this > is untrusted allocation triggered from userspace and should be a subject > of kmem accountingis, and as such it is controlled by the cgroup > mechanism. [1] > > As part of this change, we allow loading in mlx5 driver larger images > than 512 MB by dropping the arbitrary hard-coded value that we have > today and move to use the max device loading value which is for now 4GB. > > In addition, the first patch from the series fixes a UBSAN note in mlx5 > that was reported once the kernel was compiled with this option. > > [1] https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html > > Changes from V0: https://www.spinics.net/lists/kvm/msg299508.html > Patch #2 - Fix MAX_LOAD_SIZE to use BIT_ULL instead of BIT as was > reported by the krobot test. > > Yishai > > Jason Gunthorpe (1): > vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations > > Yishai Hadas (5): > vfio/mlx5: Fix UBSAN note > vfio/mlx5: Allow loading of larger images than 512 MB > vfio/hisi: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations > vfio/fsl-mc: Use GFP_KERNEL_ACCOUNT for userspace persistent > allocations > vfio/platform: Use GFP_KERNEL_ACCOUNT for userspace persistent > allocations > > drivers/vfio/container.c | 2 +- > drivers/vfio/fsl-mc/vfio_fsl_mc.c | 2 +- > drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c | 4 ++-- > .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 4 ++-- > drivers/vfio/pci/mlx5/cmd.c | 17 +++++++++-------- > drivers/vfio/pci/mlx5/main.c | 19 ++++++++++--------- > drivers/vfio/pci/vfio_pci_config.c | 6 +++--- > drivers/vfio/pci/vfio_pci_core.c | 7 ++++--- > drivers/vfio/pci/vfio_pci_igd.c | 2 +- > drivers/vfio/pci/vfio_pci_intrs.c | 10 ++++++---- > drivers/vfio/pci/vfio_pci_rdwr.c | 2 +- > drivers/vfio/platform/vfio_platform_common.c | 2 +- > drivers/vfio/platform/vfio_platform_irq.c | 8 ++++---- > drivers/vfio/virqfd.c | 2 +- > 14 files changed, 46 insertions(+), 41 deletions(-) The type1 IOMMU backend is notably absent here among the core files, any reason? Potentially this removes the dma_avail issue as a means to prevent userspace from creating an arbitrarily large number of DMA mappings, right? For compatibility, this might mean setting the DMA entry limit to an excessive number instead as some use cases can already hit the U16_MAX limit now. Are there any compatibility issues we should expect with this change to accounting otherwise? Also a nit, the commit logs have a persistent typo throughout "accountingis". I can fix on commit or if we decide on a respin please fix. Thanks, Alex
