From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Yishai Hadas <yishaih@nvidia.com>,
kvm@vger.kernel.org, kevin.tian@intel.com,
joao.m.martins@oracle.com, leonro@nvidia.com,
diana.craciun@oss.nxp.com, eric.auger@redhat.com,
maorg@nvidia.com, cohuck@redhat.com,
shameerali.kolothum.thodi@huawei.com
Subject: Re: [PATCH V1 vfio 0/6] Move to use cgroups for userspace persistent allocations
Date: Wed, 18 Jan 2023 11:15:07 -0400 [thread overview]
Message-ID: <Y8gM+9ptO2umgPQf@nvidia.com> (raw)
In-Reply-To: <20230117163811.591b4d6f.alex.williamson@redhat.com>
On Tue, Jan 17, 2023 at 04:38:11PM -0700, Alex Williamson wrote:
> The type1 IOMMU backend is notably absent here among the core files, any
> reason?
Mostly fear that charging alot of memory to the cgroup will become a
compatibility problem. I'd be happier if we go along the iommufd path
some more and get some field results from cgroup enablement before we
think about tackling type 1.
With this series in normal non-abusive cases this is probably only a
few pages of ram so it shouldn't be a problem. mlx5 needs huge amounts
of memory but it is new so anyone deploying a new mlx5 configuration
can set their cgroup accordingly.
If we fully do type 1 we are looking at alot of memory. eg a 1TB
guest will charge 2GB just in IOPTE structures at 4k page size. Maybe
that is enough to be a problem, I don't know.
> Potentially this removes the dma_avail issue as a means to
> prevent userspace from creating an arbitrarily large number of DMA
> mappings, right?
Yes, it is what iommufd did
> Are there any compatibility issues we should expect with this change to
> accounting otherwise?
Other than things might start hitting the limit, I don't think so?
Jason
next prev parent reply other threads:[~2023-01-18 15:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-08 15:44 [PATCH V1 vfio 0/6] Move to use cgroups for userspace persistent allocations Yishai Hadas
2023-01-08 15:44 ` [PATCH V1 vfio 1/6] vfio/mlx5: Fix UBSAN note Yishai Hadas
2023-01-08 15:44 ` [PATCH V1 vfio 2/6] vfio/mlx5: Allow loading of larger images than 512 MB Yishai Hadas
2023-01-08 15:44 ` [PATCH V1 vfio 3/6] vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations Yishai Hadas
2023-01-09 15:56 ` Joao Martins
2023-01-09 16:09 ` Yishai Hadas
2023-01-09 16:21 ` Joao Martins
2023-01-08 15:44 ` [PATCH V1 vfio 4/6] vfio/hisi: " Yishai Hadas
2023-01-08 15:44 ` [PATCH V1 vfio 5/6] vfio/fsl-mc: " Yishai Hadas
2023-01-08 15:44 ` [PATCH V1 vfio 6/6] vfio/platform: " Yishai Hadas
2023-01-09 13:11 ` [PATCH V1 vfio 0/6] Move to use cgroups " Jason Gunthorpe
2023-01-17 23:38 ` Alex Williamson
2023-01-18 15:15 ` Jason Gunthorpe [this message]
2023-01-18 17:40 ` Alex Williamson
2023-01-23 15:19 ` Yishai Hadas
2023-01-23 19:37 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8gM+9ptO2umgPQf@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=diana.craciun@oss.nxp.com \
--cc=eric.auger@redhat.com \
--cc=joao.m.martins@oracle.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leonro@nvidia.com \
--cc=maorg@nvidia.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.