On Tue, Oct 25, 2022 at 10:55:18AM -0600, Alex Williamson wrote: > On Wed, 26 Oct 2022 00:37:33 +0800 > Cindy Lu <l...@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.