Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1138342ybe; Wed, 4 Sep 2019 13:16:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqyqtls+d3PE7+jAq+H1SaHPyknWulZV9AxChgvMYkxcXFhxi34OFpGk/hnbu4HyZ+JdHRbR X-Received: by 2002:a65:50c8:: with SMTP id s8mr36400875pgp.339.1567628194862; Wed, 04 Sep 2019 13:16:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567628194; cv=none; d=google.com; s=arc-20160816; b=OXBr0Bi/9EUV2pyCPecmn5HelrsysZG00YzCJTmUg7BLeuUSJ5oCY7nOurebLSVH3V k/YT3RUNx/RFSPR35duO3neCwi4cQmYJ39NMy3VNZpaufL7+kUBiuYJjA5q6g7EYgEUM mYxiuPVUV1umjr5Ht7vGBy+jsEG4VWdyRzxuLUCpO7IIkzoOf+BjdYiOPn5fQHqc84Dt DOAHkod5Up6043i4q+M/XD8GgxOpNG83J59Idc4G4oNw81cetZrcSNQTh7PMg3xBFYNe QflbWhkI0UFViR0izqmiWJzyab3waclSgmH+49CLCXP7MDj+Ey/NcvV1mlZRzZfsrbul Y3xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=IVSI/3S/mgs3j0cDo+uOSTmHcYpSM9FFJdgeGgAkVxs=; b=n5SLB1FOj018ebn2msTALbJATp4WwrF9SQ2g7kQ9OAwdzbOU/6iCr+U9jbqFFEG2ui XDOop9zNZgAxLKf6qj3ObuWSQnw0PcP+EKxJtbQ4hMMz7L7X8kd6Mgfzg3zJZ3hW/UrB 9/5JAKU9eLeC7JuJgMo48EY/MXDR3uaihZxCpvIc1oEbtbY7H80emH5f1bkOScJd2Y5C BNyFKYOH7LfS2Mc+QKRWE8/9bcQfqv99wDuDo2dlVK7wAbrxVAPLke4yKLu0fVQgpelW nJ/3udxrJoo2O6F9ZVVoEBsde5qI6q7wLg+BBBQ0FQy0IwatBuYVLkbxa6/wKzj54e6a 61Xw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h24si84236pjt.22.2019.09.04.13.16.14; Wed, 04 Sep 2019 13:16:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729626AbfIDUPK (ORCPT + 99 others); Wed, 4 Sep 2019 16:15:10 -0400 Received: from mga03.intel.com ([134.134.136.65]:46955 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726495AbfIDUPJ (ORCPT ); Wed, 4 Sep 2019 16:15:09 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2019 13:15:08 -0700 X-IronPort-AV: E=Sophos;i="5.64,468,1559545200"; d="scan'208";a="187738920" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2019 13:15:07 -0700 Message-ID: Subject: Re: [PATCH v7 6/6] virtio-balloon: Add support for providing unused page reports to host From: Alexander Duyck To: "Michael S. Tsirkin" , Alexander Duyck Cc: nitesh@redhat.com, kvm@vger.kernel.org, david@redhat.com, dave.hansen@intel.com, linux-kernel@vger.kernel.org, willy@infradead.org, mhocko@kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, virtio-dev@lists.oasis-open.org, osalvador@suse.de, yang.zhang.wz@gmail.com, pagupta@redhat.com, riel@surriel.com, konrad.wilk@oracle.com, lcapitulino@redhat.com, wei.w.wang@intel.com, aarcange@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com Date: Wed, 04 Sep 2019 13:15:07 -0700 In-Reply-To: <20190904151506-mutt-send-email-mst@kernel.org> References: <20190904150920.13848.32271.stgit@localhost.localdomain> <20190904151102.13848.65770.stgit@localhost.localdomain> <20190904151506-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2019-09-04 at 15:17 -0400, Michael S. Tsirkin wrote: > On Wed, Sep 04, 2019 at 08:11:02AM -0700, Alexander Duyck wrote: > > From: Alexander Duyck > > > > 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 > > --- > > drivers/virtio/Kconfig | 1 + > > drivers/virtio/virtio_balloon.c | 65 +++++++++++++++++++++++++++++++++++ > > include/uapi/linux/virtio_balloon.h | 1 + > > 3 files changed, 67 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..0b400bb382c0 100644 > > --- a/drivers/virtio/virtio_balloon.c > > +++ b/drivers/virtio/virtio_balloon.c > > @@ -19,6 +19,7 @@ > > #include > > #include > > #include > > +#include > > > > /* > > * 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,32 @@ 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, err; > > + > > + /* We should always be able to add these buffers to an empty queue. */ > > + err = virtqueue_add_inbuf(vq, ph_dev_info->sg, nents, vb, > > + GFP_NOWAIT | __GFP_NOWARN); > > + > > + /* > > + * In the extremely unlikely case that something has changed and we > > + * are able to trigger an error we will simply display a warning > > + * and exit without actually processing the pages. > > + */ > > + if (WARN_ON(err)) > > + return; > > + > > + virtqueue_kick(vq); > > + > > + /* When host has read buffer, this completes via balloon_ack */ > > + wait_event(vb->acked, virtqueue_get_buf(vq, &unused)); > > +} > > + > > So just to make sure I understand, this always passes a single > buf to the vq and then waits until that completes, correct? Correct. > Thus there are never outstanding bufs on the vq and this > is why we don't need e.g. any cleanup. Yes. Basically this will wait until the queue has been processed by the host before we process any additional pages. We can't have the pages in an unknown state when we put them back so we have to wait here until we know they have been fully reported to the host.