From patchwork Tue Jul 17 22:47:31 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 945395 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41Vb6L3QMkz9s0w for ; Wed, 18 Jul 2018 08:48:25 +1000 (AEST) Received: from localhost ([::1]:33752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ffYlW-0005Ql-Px for incoming@patchwork.ozlabs.org; Tue, 17 Jul 2018 18:48:18 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ffYkt-0005Qg-D6 for qemu-devel@nongnu.org; Tue, 17 Jul 2018 18:47:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ffYko-0000ha-If for qemu-devel@nongnu.org; Tue, 17 Jul 2018 18:47:39 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58878 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ffYko-0000gF-D2 for qemu-devel@nongnu.org; Tue, 17 Jul 2018 18:47:34 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 395CD8182D06; Tue, 17 Jul 2018 22:47:32 +0000 (UTC) Received: from gimli.home (ovpn-116-29.phx2.redhat.com [10.3.116.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id A181F2026D68; Tue, 17 Jul 2018 22:47:31 +0000 (UTC) From: Alex Williamson To: qemu-devel@nongnu.org Date: Tue, 17 Jul 2018 16:47:31 -0600 Message-ID: <20180717222721.14019.27548.stgit@gimli.home> User-Agent: StGit/0.18-102-gdf9f MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 17 Jul 2018 22:47:32 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 17 Jul 2018 22:47:32 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'alex.williamson@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [RFC PATCH 0/3] Balloon inhibit enhancements X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Directly assigned vfio devices have never been compatible with ballooning. Zapping MADV_DONTNEED pages happens completely independent of vfio page pinning and IOMMU mapping, leaving us with inconsistent GPA to HPA mapping between vCPUs and assigned devices when the balloon deflates. Mediated devices can theoretically do better, if we make the assumption that the mdev vendor driver is fully synchronized to the actual working set of the guest driver. In that case the guest balloon driver should never be able to allocate an mdev pinned page for balloon inflation. Unfortunately, QEMU can't know the workings of the vendor driver pinning, and doesn't actually know the difference between mdev devices and directly assigned devices. Until we can sort out how the vfio IOMMU backend can tell us if ballooning is safe, the best approach is to disabling ballooning any time a vfio devices is attached. To do that, simply make the balloon inhibitor a counter rather than a boolean, fixup a case where KVM can then simply use the inhibit interface, and inhibit ballooning any time a vfio device is attached. I'm expecting we'll expose some sort of flag similar to KVM_CAP_SYNC_MMU from the vfio IOMMU for cases where we can resolve this. An addition we could consider here would be yet another device option for vfio, such as x-disable-balloon-inhibit, in case there are mdev devices that behave in a manner compatible with ballooning. Please let me know if this looks like a good idea. Thanks, Alex --- Alex Williamson (3): balloon: Allow nested inhibits kvm: Use inhibit to prevent ballooning without synchronous mmu vfio: Inhibit ballooning accel/kvm/kvm-all.c | 4 ++++ balloon.c | 7 ++++--- hw/vfio/common.c | 6 ++++++ hw/virtio/virtio-balloon.c | 4 +--- 4 files changed, 15 insertions(+), 6 deletions(-)