On Thu, 27 Oct 2022 at 04:40, Michael S. Tsirkin <m...@redhat.com> wrote:
>
> 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.
>
Thanks Alex and Micheal, I will send a new version with this fix very soon
Thanks
Cindy
