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 87830C352AA for ; Wed, 2 Oct 2019 14:17:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2CA8321920 for ; Wed, 2 Oct 2019 14:17:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2CA8321920 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C50A66B0005; Wed, 2 Oct 2019 10:17:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C00E86B0006; Wed, 2 Oct 2019 10:17:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B16CF6B0007; Wed, 2 Oct 2019 10:17:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0060.hostedemail.com [216.40.44.60]) by kanga.kvack.org (Postfix) with ESMTP id 918116B0005 for ; Wed, 2 Oct 2019 10:17:10 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 34BAC181AC9AE for ; Wed, 2 Oct 2019 14:17:10 +0000 (UTC) X-FDA: 75999046620.19.note72_78c0c6b3a805d X-HE-Tag: note72_78c0c6b3a805d X-Filterd-Recvd-Size: 5400 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Oct 2019 14:17:09 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 444F269089; Wed, 2 Oct 2019 14:17:08 +0000 (UTC) Received: from redhat.com (ovpn-112-19.rdu2.redhat.com [10.10.112.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79E37600CE; Wed, 2 Oct 2019 14:16:58 +0000 (UTC) Date: Wed, 2 Oct 2019 10:15:42 -0400 From: Jerome Glisse To: Paolo Bonzini Cc: Mircea CIRJALIU - MELIU , Adalbert =?utf-8?B?TGF6xINy?= , Matthew Wilcox , "kvm@vger.kernel.org" , "linux-mm@kvack.org" , "virtualization@lists.linux-foundation.org" , Radim =?utf-8?B?S3LEjW3DocWZ?= , Konrad Rzeszutek Wilk , Tamas K Lengyel , Mathieu Tarral , Samuel =?iso-8859-1?Q?Laur=E9n?= , Patrick Colp , Jan Kiszka , Stefan Hajnoczi , Weijiang Yang , Yu C , Mihai =?utf-8?B?RG9uyJt1?= Subject: Re: DANGER WILL ROBINSON, DANGER Message-ID: <20191002141542.GA5669@redhat.com> References: <20190809162444.GP5482@bombadil.infradead.org> <1565694095.D172a51.28640.@15f23d3a749365d981e968181cce585d2dcb3ffa> <20190815191929.GA9253@redhat.com> <20190815201630.GA25517@redhat.com> <20190905180955.GA3251@redhat.com> <5b0966de-b690-fb7b-5a72-bc7906459168@redhat.com> <20191002192714.GA5020@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 02 Oct 2019 14:17:08 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 02, 2019 at 03:46:30PM +0200, Paolo Bonzini wrote: > On 02/10/19 21:27, Jerome Glisse wrote: > > On Tue, Sep 10, 2019 at 07:49:51AM +0000, Mircea CIRJALIU - MELIU wro= te: > >>> On 05/09/19 20:09, Jerome Glisse wrote: > >>>> Not sure i understand, you are saying that the solution i outline > >>>> above does not work ? If so then i think you are wrong, in the abo= ve > >>>> solution the importing process mmap a device file and the resultin= g > >>>> vma is then populated using insert_pfn() and constantly keep > >>>> synchronize with the target process through mirroring which means = that > >>>> you never have to look at the struct page ... you can mirror any k= ind > >>>> of memory from the remote process. > >>> > >>> If insert_pfn in turn calls MMU notifiers for the target VMA (which= would be > >>> the KVM MMU notifier), then that would work. Though I guess it wou= ld be > >>> possible to call MMU notifier update callbacks around the call to i= nsert_pfn. > >> > >> Can't do that. > >> First, insert_pfn() uses set_pte_at() which won't trigger the MMU no= tifier on > >> the target VMA. It's also static, so I'll have to access it thru vmf= _insert_pfn() > >> or vmf_insert_mixed(). > >=20 > > Why would you need to target mmu notifier on target vma ? >=20 > If the mapping of the source VMA changes, mirroring can update the > target VMA via insert_pfn. But what ensures that KVM's MMU notifier > dismantles its own existing page tables (so that they can be recreated > with the new mapping from the source VMA)? >=20 So just to make sure i follow we have: - qemu process on host with anonymous vma -> host cpu page table - kvm which maps host anonymous vma to guest -> kvm guest page table - kvm inspector process which mirror vma from qemu process -> inspector process page table AFAIK the KVM notifier's will clear the kvm guest page table whenever necessary (through kvm_mmu_notifier_invalidate_range_start). This is what ensure that KVM's dismatles its own mapping, it abides to mmu- notifier callbacks. If you did not you would have bugs (at least i expect so). Am i wrong here ? The mirroring kernel driver would also register the notifier against the quemu process and would also abide to notifier callbacks. What you want to maintain at all times is that none of the actors above ever look at different page for the same virtual address (ie one looking at older page while another look at new page). This is where you have helper like HMM that make sure that you can not populate the mirroring vma while a notifier is on going. Which means that everything is serialize on the notifier. Cheers, J=E9r=F4me