Re: [PATCH v30 2/4] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Apr 05, 2018 at 03:47:28PM +0000, Wang, Wei W wrote:
> On Thursday, April 5, 2018 10:04 PM, Michael S. Tsirkin wrote:
> > On Thu, Apr 05, 2018 at 02:05:03AM +0000, Wang, Wei W wrote:
> > > On Thursday, April 5, 2018 9:12 AM, Michael S. Tsirkin wrote:
> > > > On Thu, Apr 05, 2018 at 12:30:27AM +0000, Wang, Wei W wrote:
> > > > > On Wednesday, April 4, 2018 10:08 PM, Michael S. Tsirkin wrote:
> > > > > > On Wed, Apr 04, 2018 at 10:07:51AM +0800, Wei Wang wrote:
> > > > > > > On 04/04/2018 02:47 AM, Michael S. Tsirkin wrote:
> > > > > > > > On Wed, Apr 04, 2018 at 12:10:03AM +0800, Wei Wang wrote:
> > > > > I'm afraid the driver couldn't be aware if the added hints are
> > > > > stale or not,
> > > >
> > > >
> > > > No - I mean that driver has code that compares two values and stops
> > > > reporting. Can one of the values be stale?
> > >
> > > The driver compares "vb->cmd_id_use != vb->cmd_id_received" to decide
> > > if it needs to stop reporting hints, and cmd_id_received is what the
> > > driver reads from host (host notifies the driver to read for the
> > > latest value). If host sends a new cmd id, it will notify the guest to
> > > read again. I'm not sure how that could be a stale cmd id (or maybe I
> > > misunderstood your point here?)
> > >
> > > Best,
> > > Wei
> > 
> > The comparison is done in one thread, the update in another one.
> 
> I think this isn't something that could be solved by adding a lock,
> unless host waits for the driver's ACK about finishing the update
> (this is not agreed in the QEMU part discussion).
> 
> Actually virtio_balloon has F_IOMMU_PLATFORM disabled, maybe we don't
> need to worry about that using DMA api case (we only have gpa added to
> the vq, and having some entries stay in the vq seems fine). For this
> feature, I think it would not work with F_IOMMU enabled either.

Adding a code comment explaining all this might be a good idea.

> If there is any further need (I couldn't think of a need so far), I
> think we could consider to let host inject a vq interrupt at some
> point, and then the driver handler can do the virtqueue_get_buf work.
> 
> Best,
> Wei