qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restr


From: Alex Williamson
Subject: Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction
Date: Tue, 7 Aug 2018 13:53:03 -0600

On Tue, 7 Aug 2018 22:44:56 +0300
"Michael S. Tsirkin" <address@hidden> wrote:

> On Tue, Aug 07, 2018 at 01:31:21PM -0600, Alex Williamson wrote:
> > v3:
> >  - Drop "nested" term in commit log (David)
> >  - Adopt suggested wording in ccw code (Cornelia)
> >  - Explain balloon inhibitor usage in vfio common (Peter)
> >  - Fix to call inhibitor prior to re-using existing containers
> >    to avoid gap that pinning may have occurred in set container
> >    ioctl (self) - Peter, this change is the reason I didn't
> >    include your R-b.
> >  - Add R-b to patches 1 & 2
> > 
> > v2:
> >  - Use atomic ops for balloon inhibit counter (Peter)
> >  - Allow endpoint driver opt-in for ballooning, vfio-ccw opt-in by
> >    default, vfio-pci opt-in by device option, only allowed for mdev
> >    devices, no support added for platform as there are no platform
> >    mdev devices.
> > 
> > See patch 3/4 for detailed explanation why ballooning and device
> > assignment typically don't mix.  If this eventually changes, flags
> > on the iommu info struct or perhaps device info struct can inform
> > us for automatic opt-in.  Thanks,
> > 
> > Alex  
> 
> One of the issues with pass-through is that it breaks overcommit
> through swap. ballooning seems to offer one solution, instead of
> making it work this patch just attempts to block ballooning.
> 
> I guess it's better than corrupting memory but I personally find this
> approach disappointing.

Memory hotplug is the way to achieve variable density with assigned
device VMs, otherwise look towards approaches like mdev and shared
virtual addresses with PASID support.  We cannot shoehorn page faulting
without both hardware and software support.  Some class of "legacy"
device assignment will always have this incompatibility.  Thanks,

Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]