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 E9993C32792 for ; Thu, 3 Oct 2019 18:32:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CB5A020865 for ; Thu, 3 Oct 2019 18:32:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388684AbfJCScf (ORCPT ); Thu, 3 Oct 2019 14:32:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43850 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731346AbfJCSce (ORCPT ); Thu, 3 Oct 2019 14:32:34 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4B26A3090FDA; Thu, 3 Oct 2019 18:32:34 +0000 (UTC) Received: from redhat.com (ovpn-112-55.rdu2.redhat.com [10.10.112.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 828EE608A5; Thu, 3 Oct 2019 18:32:25 +0000 (UTC) Date: Thu, 3 Oct 2019 14:31:08 -0400 From: Jerome Glisse To: Mircea CIRJALIU - MELIU Cc: Paolo Bonzini , 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: <20191003183108.GA3557@redhat.com> References: <20191002192714.GA5020@redhat.com> <20191002141542.GA5669@redhat.com> <20191002170429.GA8189@redhat.com> <20191003154233.GA4421@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.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Thu, 03 Oct 2019 18:32:34 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Oct 03, 2019 at 04:42:20PM +0000, Mircea CIRJALIU - MELIU wrote: > > On 03/10/19 17:42, Jerome Glisse wrote: > > > All that is needed is to make sure that vm_normal_page() will see > > > those pte (inside the process that is mirroring the other process) as > > > special which is the case either because insert_pfn() mark the pte as > > > special or the kvm device driver which control the vm_operation struct > > > set a > > > find_special_page() callback that always return NULL, or the vma has > > > either VM_PFNMAP or VM_MIXEDMAP set (which is the case with > > insert_pfn). > > > > > > So you can keep the existing kvm code unmodified. > > > > Great, thanks. And KVM is already able to handle > > VM_PFNMAP/VM_MIXEDMAP, so that should work. > > This means setting VM_PFNMAP/VM_MIXEDMAP on the anon VMA that acts as the VM's system RAM. > Will it have any side effects? You do not set it up on the anonymous vma but on the mmap of the kvm device file, the resulting vma is under the control of the kvm device file and is not an anonymous vma but a "device" special vma. So in summary, the source qemu process has anonymous vma (regular libc malloc for instance). The introspector qemu process which mirror the the source qemu use mmap on /dev/kvm (assuming you can reuse the kvm device file for this otherwise you can introduce a new kvm device file). The resulting mmap inside the introspector qemu process is a vma which has vma->vm_file pointing to the kvm device file and has VM_PFNMAP or VM_MIXEDMAP (i think you want the former). On architecture with ARCH_SPECIAL_PTE the pte will be mark as special when using insert_pfn() on other architecture you can either rely on VM_PFNMAP/VM_MIXEDMAP flag or set a specific find_special_page() callbacks in vm_ops. I am at a conference right now but i will put an example of what i mean next week. Cheers, Jérôme