On Tue, 2019-08-06 at 07:31 -0400, Michael S. Tsirkin wrote:
> On Mon, Aug 05, 2019 at 09:27:16AM -0700, Alexander Duyck wrote:
> > On Mon, 2019-08-05 at 12:00 -0400, Nitesh Narayan Lal wrote:
> > > On 8/1/19 6:38 PM, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@xxxxxxxxxxxxxxx>
> > > >
> > > > Add support for the page reporting feature provided by virtio-balloon.
> > > > Reporting differs from the regular balloon functionality in that is is
> > > > much less durable than a standard memory balloon. Instead of creating a
> > > > list of pages that cannot be accessed the pages are only inaccessible
> > > > while they are being indicated to the virtio interface. Once the
> > > > interface has acknowledged them they are placed back into their respective
> > > > free lists and are once again accessible by the guest system.
> > > >
> > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@xxxxxxxxxxxxxxx>
> > > > ---
> > > > drivers/virtio/Kconfig | 1 +
> > > > drivers/virtio/virtio_balloon.c | 56 +++++++++++++++++++++++++++++++++++
> > > > include/uapi/linux/virtio_balloon.h | 1 +
> > > > 3 files changed, 58 insertions(+)
> > > >
> > > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > > index 078615cf2afc..4b2dd8259ff5 100644
> > > > --- a/drivers/virtio/Kconfig
> > > > +++ b/drivers/virtio/Kconfig
> > > > @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
> > > > tristate "Virtio balloon driver"
> > > > depends on VIRTIO
> > > > select MEMORY_BALLOON
> > > > + select PAGE_REPORTING
> > > > ---help---
> > > > This driver supports increasing and decreasing the amount
> > > > of memory within a KVM guest.
> > > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > > > index 2c19457ab573..971fe924e34f 100644
> > > > --- a/drivers/virtio/virtio_balloon.c
> > > > +++ b/drivers/virtio/virtio_balloon.c
> > > > @@ -19,6 +19,7 @@
> > > > #include <linux/mount.h>
> > > > #include <linux/magic.h>
> > > > #include <linux/pseudo_fs.h>
> > > > +#include <linux/page_reporting.h>
> > > >
> > > > /*
> > > > * Balloon device works in 4K page units. So each page is pointed to by
> > > > @@ -37,6 +38,9 @@
> > > > #define VIRTIO_BALLOON_FREE_PAGE_SIZE \
> > > > (1 << (VIRTIO_BALLOON_FREE_PAGE_ORDER + PAGE_SHIFT))
> > > >
> > > > +/* limit on the number of pages that can be on the reporting vq */
> > > > +#define VIRTIO_BALLOON_VRING_HINTS_MAX 16
> > > > +
> > > > #ifdef CONFIG_BALLOON_COMPACTION
> > > > static struct vfsmount *balloon_mnt;
> > > > #endif
> > > > @@ -46,6 +50,7 @@ enum virtio_balloon_vq {
> > > > VIRTIO_BALLOON_VQ_DEFLATE,
> > > > VIRTIO_BALLOON_VQ_STATS,
> > > > VIRTIO_BALLOON_VQ_FREE_PAGE,
> > > > + VIRTIO_BALLOON_VQ_REPORTING,
> > > > VIRTIO_BALLOON_VQ_MAX
> > > > };
> > > >
> > > > @@ -113,6 +118,10 @@ struct virtio_balloon {
> > > >
> > > > /* To register a shrinker to shrink memory upon memory pressure */
> > > > struct shrinker shrinker;
> > > > +
> > > > + /* Unused page reporting device */
> > > > + struct virtqueue *reporting_vq;
> > > > + struct page_reporting_dev_info ph_dev_info;
> > > > };
> > > >
> > > > static struct virtio_device_id id_table[] = {
> > > > @@ -152,6 +161,23 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
> > > >
> > > > }
> > > >
> > > > +void virtballoon_unused_page_report(struct page_reporting_dev_info *ph_dev_info,
> > > > + unsigned int nents)
> > > > +{
> > > > + struct virtio_balloon *vb =
> > > > + container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> > > > + struct virtqueue *vq = vb->reporting_vq;
> > > > + unsigned int unused;
> > > > +
> > > > + /* We should always be able to add these buffers to an empty queue. */
> > > > + virtqueue_add_inbuf(vq, ph_dev_info->sg, nents, vb,
> > > > + GFP_NOWAIT | __GFP_NOWARN);
> > >
> > > I think you should handle allocation failure here. It is a possibility, isn't?
> > > Maybe return an error or even disable page hinting/reporting?
> > >
> >
> > I don't think it is an issue I have to worry about. Specifically I am
> > limiting the size of the scatterlist based on the size of the vq. As such
> > I will never exceed the size and should be able to use it to store the
> > scatterlist directly.
>
> I agree. But it can't hurt to BUG_ON for good measure.
>
I wouldn't use a BUG_ON as that seems overkill. No need to panic the
kernel just because we couldn't report some idle pages.
I can probably do something like:
if (WARN_ON(err))
return;
That way the unused page reporting can run to completion still and the
fact that we aren't really hinting on the pages would effectively be no
different then if we had a direct assigned device or shared memory in the
hypervisor.
