From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 414B4C4646D for ; Mon, 6 Aug 2018 19:58:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EBD1A208A3 for ; Mon, 6 Aug 2018 19:58:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBD1A208A3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387528AbeHFWIv (ORCPT ); Mon, 6 Aug 2018 18:08:51 -0400 Received: from gate.crashing.org ([63.228.1.57]:52613 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732921AbeHFWIv (ORCPT ); Mon, 6 Aug 2018 18:08:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w76Jv0VW002428; Mon, 6 Aug 2018 14:57:01 -0500 Message-ID: Subject: Re: [RFC 0/4] Virtio uses DMA API for all devices From: Benjamin Herrenschmidt To: "Michael S. Tsirkin" Cc: Christoph Hellwig , Will Deacon , Anshuman Khandual , virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, aik@ozlabs.ru, robh@kernel.org, joe@perches.com, elfring@users.sourceforge.net, david@gibson.dropbear.id.au, jasowang@redhat.com, mpe@ellerman.id.au, linuxram@us.ibm.com, haren@linux.vnet.ibm.com, paulus@samba.org, srikar@linux.vnet.ibm.com, robin.murphy@arm.com, jean-philippe.brucker@arm.com, marc.zyngier@arm.com Date: Tue, 07 Aug 2018 05:56:59 +1000 In-Reply-To: <20180806164106-mutt-send-email-mst@kernel.org> References: <20180802200646-mutt-send-email-mst@kernel.org> <20180802225738-mutt-send-email-mst@kernel.org> <20180803070507.GA1344@infradead.org> <20180803220443-mutt-send-email-mst@kernel.org> <051fd78e15595b414839fa8f9d445b9f4d7576c6.camel@kernel.crashing.org> <20180805031046-mutt-send-email-mst@kernel.org> <20180806164106-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.4 (3.28.4-1.fc28) 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 Mon, 2018-08-06 at 16:46 +0300, Michael S. Tsirkin wrote: > > > Right, we'll need some quirk to disable balloons in the guest I > > suppose. > > > > Passing something from libvirt is cumbersome because the end user may > > not even need to know about secure VMs. There are use cases where the > > security is a contract down to some special application running inside > > the secure VM, the sysadmin knows nothing about. > > > > Also there's repercussions all the way to admin tools, web UIs etc... > > so it's fairly wide ranging. > > > > So as long as we only need to quirk a couple of devices, it's much > > better contained that way. > > So just the balloon thing already means that yes management and all the > way to the user tools must know this is going on. Otherwise > user will try to inflate the balloon and wonder why this does not work. There is *dozens* of management systems out there, not even all open source, we won't ever be able to see the end of the tunnel if we need to teach every single of them, including end users, about platform specific new VM flags like that. .../... > Here's another example: you can't migrate a secure vm to hypervisor > which doesn't support this feature. Again management tools above libvirt > need to know otherwise they will try. There will have to be a new machine type for that I suppose, yes, though it's not just the hypervisor that needs to know about the modified migration stream, it's also the need to have a compatible ultravisor with the right keys on the other side. So migration is going to be special and require extra admin work in all cases yes. But not all secure VMs are meant to be migratable. In any case, back to the problem at hand. What a qemu flag gives us is just a way to force iommu at VM creation time. This is rather sub-optimal, we don't really want the iommu in the way, so it's at best a "workaround", and it's not really solving the real problem. As I said replying to Christoph, we are "leaking" into the interface something here that is really what's the VM is doing to itself, which is to stash its memory away in an inaccessible place. Cheers, Ben.