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.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,SUBJ_ALL_CAPS,USER_AGENT_SANE_1 autolearn=no 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 A7F39C47404 for ; Fri, 4 Oct 2019 11:47:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8583520867 for ; Fri, 4 Oct 2019 11:47:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730020AbfJDLrC (ORCPT ); Fri, 4 Oct 2019 07:47:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59684 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725826AbfJDLrC (ORCPT ); Fri, 4 Oct 2019 07:47:02 -0400 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 52DF9B62C for ; Fri, 4 Oct 2019 11:47:01 +0000 (UTC) Received: by mail-wm1-f70.google.com with SMTP id s19so1512128wmj.0 for ; Fri, 04 Oct 2019 04:47:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+JwHgoEwrxaFZwrDe7mi7c34P6AQjAcW/4AJU211S7o=; b=ryN/3Jn8DzAIPYgYuwmYJK0AYRqiqWMyG4HIeiLfJ8rPGD2laOX2hVEl8AkFqAi1wj dCUUnxpIOsn+a0L/PhhJ4JKyXTgicRFImelTFic8MmjNyoziIf9tNfYNwggdihE0vcE+ //Vpzmn1xOxb3gY6Z6U496+NfaH/WT3FqDgDHW6T1eaiDurAniZugLtpLEpWGnjBCCdE Sz+7wLZF+N8e43L3Gjc+wdQL5pBGr584gXuFjiHmr8eDieZbFqWihJ2zWDb1jYTJX/Sd YuOM3LB+TV+FC4mtyOQZJXqrqBqPDRgm9OyZztxQh9GpOLdHwpcRI+XTkl8IVPT2OJKv htrA== X-Gm-Message-State: APjAAAUUfa2ywxOGMls0FCmNUIpqpEeIo/ObFoSpvohQDhdfQDLWyR54 YJ3aG5J60fRHYgHQ6hUB/4r1SoMNWECHAO++ptGnl6g31qffi+atCRmeFiQgvql59BCDf4/RBEZ PK3nFC8ctpDop X-Received: by 2002:a1c:61d6:: with SMTP id v205mr9957507wmb.35.1570189619910; Fri, 04 Oct 2019 04:46:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqyH/UQA0Hna+4tQRdNy2xgtBfIwlleCnezIJHKLxXIn6EMeOpPWe6+zaMeL8aGp+kphYLAp6g== X-Received: by 2002:a1c:61d6:: with SMTP id v205mr9957481wmb.35.1570189619580; Fri, 04 Oct 2019 04:46:59 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:e56d:fbdf:8b79:c79c? ([2001:b07:6468:f312:e56d:fbdf:8b79:c79c]) by smtp.gmail.com with ESMTPSA id y186sm11299530wmb.41.2019.10.04.04.46.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Oct 2019 04:46:58 -0700 (PDT) Subject: Re: DANGER WILL ROBINSON, DANGER To: Mircea CIRJALIU - MELIU , Jerome Glisse Cc: =?UTF-8?Q?Adalbert_Laz=c4=83r?= , Matthew Wilcox , "kvm@vger.kernel.org" , "linux-mm@kvack.org" , "virtualization@lists.linux-foundation.org" , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Konrad Rzeszutek Wilk , Tamas K Lengyel , Mathieu Tarral , =?UTF-8?Q?Samuel_Laur=c3=a9n?= , Patrick Colp , Jan Kiszka , Stefan Hajnoczi , Weijiang Yang , Yu C , =?UTF-8?Q?Mihai_Don=c8=9bu?= References: <20191002192714.GA5020@redhat.com> <20191002141542.GA5669@redhat.com> <20191002170429.GA8189@redhat.com> <20191003154233.GA4421@redhat.com> <20191003183108.GA3557@redhat.com> From: Paolo Bonzini Openpgp: preference=signencrypt Message-ID: <7ccbc431-0ca6-0049-fe60-ad232c628209@redhat.com> Date: Fri, 4 Oct 2019 13:46:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 04/10/19 11:41, Mircea CIRJALIU - MELIU wrote: > I get it so far. I have a patch that does mirroring in a separate VMA. > We create an extra VMA with VM_PFNMAP/VM_MIXEDMAP that mirrors the > source VMA in the other QEMU and is refreshed by the device MMU notifier. So for example on the host you'd have a new ioctl on the kvm file descriptor. You pass a size and you get back a file descriptor for that guest's physical memory, which is mmap-able up to the size you specified in the ioctl. In turn, the file descriptor would have ioctls to map/unmap ranges of the guest memory into its mmap-able range. Accessing an unmapped range produces a SIGSEGV. When asked via the QEMU monitor, QEMU will create the file descriptor and pass it back via SCM_RIGHTS. The management application can then use it to hotplug memory into the destination... > Create a new memslot based on the mirror VMA, hotplug it into the guest as > new memory device (is this possible?) and have a guest-side driver allocate > pages from that area. ... using the existing ivshmem device, whose BAR can be accessed and mmap-ed from the guest via sysfs. In other words, the hotplugging will use the file descriptor returned by QEMU when creating the ivshmem device. We then need an additional mechanism to invoke the map/unmap ioctls from the guest. Without writing a guest-side driver it is possible to: - pass a socket into the "create guest physical memory view" ioctl above. KVM will then associate that KVMI socket with the newly created file descriptor. - use KVMI messages to that socket to map/unmap sections of memory > Redirect (some) GFN->HVA translations into the new VMA based on a table > of addresses required by the introspector process. That would be tricky because there are multiple paths (gfn_to_page, gfn_to_pfn, etc.). There is some complication in this because the new device has to be plumbed at multiple levels (KVM, QEMU, libvirt). But it seems like a very easily separated piece of code (except for the KVMI socket part, which can be added later), so I suggest that you contribute the KVM parts first. Paolo