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 6A910C352AA for ; Wed, 2 Oct 2019 14:17:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4972121920 for ; Wed, 2 Oct 2019 14:17:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727762AbfJBORJ (ORCPT ); Wed, 2 Oct 2019 10:17:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49720 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727210AbfJBORJ (ORCPT ); Wed, 2 Oct 2019 10:17:09 -0400 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 Content-Transfer-Encoding: 8bit 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) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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 wrote: > >>> 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 above > >>>> solution the importing process mmap a device file and the resulting > >>>> 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 kind > >>>> 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 would be > >>> possible to call MMU notifier update callbacks around the call to insert_pfn. > >> > >> Can't do that. > >> First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on > >> the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() > >> or vmf_insert_mixed(). > > > > Why would you need to target mmu notifier on target vma ? > > 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)? > 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érôme