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 00D32C4360C for ; Wed, 2 Oct 2019 20:10:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F16720673 for ; Wed, 2 Oct 2019 20:10:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F16720673 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 098436B0003; Wed, 2 Oct 2019 16:10:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0496A6B0006; Wed, 2 Oct 2019 16:10:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E79FF6B0007; Wed, 2 Oct 2019 16:10:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) by kanga.kvack.org (Postfix) with ESMTP id BEC306B0003 for ; Wed, 2 Oct 2019 16:10:26 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 5D6F2812B for ; Wed, 2 Oct 2019 20:10:26 +0000 (UTC) X-FDA: 75999936852.15.line80_39caa3fec030 X-HE-Tag: line80_39caa3fec030 X-Filterd-Recvd-Size: 5581 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Oct 2019 20:10:24 +0000 (UTC) Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (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 47A2A83F3E for ; Wed, 2 Oct 2019 20:10:23 +0000 (UTC) Received: by mail-wr1-f71.google.com with SMTP id v18so31815wro.16 for ; Wed, 02 Oct 2019 13:10:23 -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=ECzmcjCSbbcsFSzX1mjy2hRL/7INCALmJsVRlbIqA+M=; b=oPept4i5R1I2s4QwEpWTGDU8f4f76x4Gkk4388NYQ0O7yJLgvNZg5zsF3TB/MANDjd r4w/LPvMgT/GhtNskJUysPH84h43lYXBm4oY9FeG6wOcqgAqbv/ZCW0WUN99oa1xQlBi Hskm2h36J/acx5MbQvaoLtYuX2vnOB6/VkxBTrgbUHTkdQ5V8i/QrxgZi6jw947PBist UPQlAP9ih7niAofRzcpWuixmFWRp15WIvSzAxW0RT+plxjWUrbUyso1ztomyXZv5AnYw qrzfs2b6N/XYeHv+Bhu+FvI7zF6eSqortQimxmxhAINk5IEubhAnSLouwCGtlrg6EgWF V/Jw== X-Gm-Message-State: APjAAAVyKjS9+b65erI7WQKelEzFJ4qgvo0uTRurrGrHUkxHtbfZlKdP lWFpdpAaoOKh5aJbaKno07hXvwPd8OwRLiK/lKfyWUVGvP2yRulNXNC1uqI9wJsjn+0JgtmI377 bIx2EAADG44U= X-Received: by 2002:a5d:5185:: with SMTP id k5mr4309032wrv.341.1570047021835; Wed, 02 Oct 2019 13:10:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwCrWt+T8lq0j3jrbvKKSdlpqYZ0reHvLDTlwAHJf9pBgzMN4snDZo/L2kojw/X0EwObK+tMQ== X-Received: by 2002:a5d:5185:: with SMTP id k5mr4309009wrv.341.1570047021557; Wed, 02 Oct 2019 13:10:21 -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 94sm642951wrk.92.2019.10.02.13.10.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Oct 2019 13:10:20 -0700 (PDT) Subject: Re: DANGER WILL ROBINSON, DANGER To: Jerome Glisse Cc: Mircea CIRJALIU - MELIU , =?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: <20190815191929.GA9253@redhat.com> <20190815201630.GA25517@redhat.com> <20190905180955.GA3251@redhat.com> <5b0966de-b690-fb7b-5a72-bc7906459168@redhat.com> <20191002192714.GA5020@redhat.com> <20191002141542.GA5669@redhat.com> <20191002170429.GA8189@redhat.com> From: Paolo Bonzini Openpgp: preference=signencrypt Message-ID: Date: Wed, 2 Oct 2019 22:10:18 +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: <20191002170429.GA8189@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> 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)? >> >> The KVM inspector process is also (or can be) a QEMU that will have to >> create its own KVM guest page table. So if a page in the source VMA is >> unmapped we want: >> >> - the source KVM to invalidate its guest page table (done by the KVM MMU >> notifier) >> >> - the target VMA to be invalidated (easy using mirroring) >> >> - the target KVM to invalidate its guest page table, as a result of >> invalidation of the target VMA > > You can do the target KVM invalidation inside the mirroring invalidation > code. Why should the source and target KVMs behave differently? If the source invalidates its guest page table via MMU notifiers, so should the target. The KVM MMU notifier exists so that nothing (including mirroring) needs to know that there is KVM on the other side. Any interaction between KVM page tables and VMAs must be mediated by MMU notifiers, anything else is unacceptable. If it is possible to invoke the MMU notifiers around the calls to insert_pfn, that of course would be perfect. Thanks, Paolo