Re: [PATCH v3 1/2] vfio: move the function vfio_get_xlat_addr() to memory.c

[Michael S. Tsirkin]

On Tue, Oct 25, 2022 at 10:55:18AM -0600, Alex Williamson wrote:
> On Wed, 26 Oct 2022 00:37:33 +0800
> Cindy Lu <lulu@redhat.com> wrote:
> > diff --git a/softmmu/memory.c b/softmmu/memory.c
> > index 7ba2048836..03940c551d 100644
> > --- a/softmmu/memory.c
> > +++ b/softmmu/memory.c
> ...
> > +        /*
> > +         * Malicious VMs might trigger discarding of IOMMU-mapped memory. 
> > The
> > +         * pages will remain pinned inside vfio until unmapped, resulting 
> > in a
> > +         * higher memory consumption than expected. If memory would get
> > +         * populated again later, there would be an inconsistency between 
> > pages
> > +         * pinned by vfio and pages seen by QEMU. This is the case until
> > +         * unmapped from the IOMMU (e.g., during device reset).
> > +         *
> > +         * With malicious guests, we really only care about pinning more 
> > memory
> > +         * than expected. RLIMIT_MEMLOCK set for the user/process can 
> > never be
> > +         * exceeded and can be used to mitigate this problem.
> > +         */
> > +        warn_report_once("Using vfio with vIOMMUs and coordinated 
> > discarding of"
> > +                         " RAM (e.g., virtio-mem) works, however, 
> > malicious"
> > +                         " guests can trigger pinning of more memory than"
> > +                         " intended via an IOMMU. It's possible to 
> > mitigate "
> > +                         " by setting/adjusting RLIMIT_MEMLOCK.");
> 
> Looks like the comment and warning still need to be generalized for
> shared use here.  Thanks,
> 
> Alex

can be a patch on top? concerned about meeting the soft freeze here.