From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: DANGER WILL ROBINSON, DANGER Date: Thu, 5 Sep 2019 14:09:55 -0400 Message-ID: <20190905180955.GA3251@redhat.com> References: <20190809160047.8319-1-alazar@bitdefender.com> <20190809160047.8319-72-alazar@bitdefender.com> <20190809162444.GP5482@bombadil.infradead.org> <1565694095.D172a51.28640.@15f23d3a749365d981e968181cce585d2dcb3ffa> <20190815191929.GA9253@redhat.com> <20190815201630.GA25517@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Mircea CIRJALIU - MELIU Cc: Tamas K Lengyel , Weijiang Yang , Yu C , "kvm@vger.kernel.org" , Radim =?utf-8?B?S3LEjW3DocWZ?= , Jan Kiszka , Samuel =?iso-8859-1?Q?Laur=E9n?= , Konrad Rzeszutek Wilk , Matthew Wilcox , "virtualization@lists.linux-foundation.org" , Adalbert =?utf-8?B?TGF6xINy?= , "linux-mm@kvack.org" , Patrick Colp , Mathieu Tarral , Stefan Hajnoczi , Paolo Bonzini , Mihai =?utf-8?B?RG9uyJt1?= List-Id: virtualization@lists.linuxfoundation.org T24gRnJpLCBBdWcgMjMsIDIwMTkgYXQgMTI6Mzk6MjFQTSArMDAwMCwgTWlyY2VhIENJUkpBTElV IC0gTUVMSVUgd3JvdGU6Cj4gPiBPbiBUaHUsIEF1ZyAxNSwgMjAxOSBhdCAwMzoxOToyOVBNIC0w NDAwLCBKZXJvbWUgR2xpc3NlIHdyb3RlOgo+ID4gPiBPbiBUdWUsIEF1ZyAxMywgMjAxOSBhdCAw MjowMTozNVBNICswMzAwLCBBZGFsYmVydCBMYXrEg3Igd3JvdGU6Cj4gPiA+ID4gT24gRnJpLCA5 IEF1ZyAyMDE5IDA5OjI0OjQ0IC0wNzAwLCBNYXR0aGV3IFdpbGNveCA8d2lsbHlAaW5mcmFkZWFk Lm9yZz4KPiA+IHdyb3RlOgo+ID4gPiA+ID4gT24gRnJpLCBBdWcgMDksIDIwMTkgYXQgMDc6MDA6 MjZQTSArMDMwMCwgQWRhbGJlcnQgTGF6xINyIHdyb3RlOgo+ID4gPiA+ID4gPiArKysgYi9pbmNs dWRlL2xpbnV4L3BhZ2UtZmxhZ3MuaAo+ID4gPiA+ID4gPiBAQCAtNDE3LDggKzQxNywxMCBAQCBQ QUdFRkxBRyhJZGxlLCBpZGxlLCBQRl9BTlkpCj4gPiA+ID4gPiA+ICAgKi8KPiA+ID4gPiA+ID4g ICNkZWZpbmUgUEFHRV9NQVBQSU5HX0FOT04JMHgxCj4gPiA+ID4gPiA+ICAjZGVmaW5lIFBBR0Vf TUFQUElOR19NT1ZBQkxFCTB4Mgo+ID4gPiA+ID4gPiArI2RlZmluZSBQQUdFX01BUFBJTkdfUkVN T1RFCTB4NAo+ID4gPiA+ID4KPiA+ID4gPiA+IFVoLiAgSG93IGRvIHlvdSBrbm93IHBhZ2UtPm1h cHBpbmcgd291bGQgb3RoZXJ3aXNlIGhhdmUgYml0IDIKPiA+IGNsZWFyPwo+ID4gPiA+ID4gV2hv J3MgZ3VhcmFudGVlaW5nIHRoYXQ/Cj4gPiA+ID4gPgo+ID4gPiA+ID4gVGhpcyBpcyBhbiBhd2Z1 bGx5IGJpZyBwYXRjaCB0byB0aGUgbWVtb3J5IG1hbmFnZW1lbnQgY29kZSwgYnVyaWVkCj4gPiA+ ID4gPiBpbiB0aGUgbWlkZGxlIG9mIGEgZ2lnYW50aWMgc2VyaWVzIHdoaWNoIGFsbW9zdCBndWFy YW50ZWVzIG5vYm9keQo+ID4gPiA+ID4gd291bGQgbG9vayBhdCBpdC4gIEkgY2FsbCBzaGVuYW5p Z2Fucy4KPiA+ID4gPiA+Cj4gPiA+ID4gPiA+IEBAIC0xMDIxLDcgKzEwMjIsNyBAQCB2b2lkIHBh Z2VfbW92ZV9hbm9uX3JtYXAoc3RydWN0IHBhZ2UKPiA+ICpwYWdlLCBzdHJ1Y3Qgdm1fYXJlYV9z dHJ1Y3QgKnZtYSkKPiA+ID4gPiA+ID4gICAqIF9fcGFnZV9zZXRfYW5vbl9ybWFwIC0gc2V0IHVw IG5ldyBhbm9ueW1vdXMgcm1hcAo+ID4gPiA+ID4gPiAgICogQHBhZ2U6CVBhZ2Ugb3IgSHVnZXBh Z2UgdG8gYWRkIHRvIHJtYXAKPiA+ID4gPiA+ID4gICAqIEB2bWE6CVZNIGFyZWEgdG8gYWRkIHBh Z2UgdG8uCj4gPiA+ID4gPiA+IC0gKiBAYWRkcmVzczoJVXNlciB2aXJ0dWFsIGFkZHJlc3Mgb2Yg dGhlIG1hcHBpbmcKPiA+ID4gPiA+ID4gKyAqIEBhZGRyZXNzOglVc2VyIHZpcnR1YWwgYWRkcmVz cyBvZiB0aGUgbWFwcGluZwo+ID4gPiA+ID4KPiA+ID4gPiA+IEFuZCBtaXhpbmcgaW4gZmx1ZmYg Y2hhbmdlcyBsaWtlIHRoaXMgaXMgYSByZWFsIG5vLW5vLiAgVHJ5IGFnYWluLgo+ID4gPiA+ID4K PiA+ID4gPgo+ID4gPiA+IE5vIGJhZCBpbnRlbnRpb25zLCBqdXN0IG92ZXJ6ZWFsb3VzLgo+ID4g PiA+IEkgZGlkbid0IHdhbnQgdG8gaGlkZSBhbnl0aGluZyBmcm9tIG91ciBwYXRjaGVzLgo+ID4g PiA+IE9uY2Ugd2UgYWR2YW5jZSB3aXRoIHRoZSBpbnRyb3NwZWN0aW9uIHBhdGNoZXMgcmVsYXRl ZCB0byBLVk0gd2UnbGwKPiA+ID4gPiBiZSBiYWNrIHdpdGggdGhlIHJlbW90ZSBtYXBwaW5nIHBh dGNoLCBzcGxpdCBhbmQgY2xlYW5lZC4KPiA+ID4KPiA+ID4gVGhleSBhcmUgbm90IGJpdCBsZWZ0 IGluIHN0cnVjdCBwYWdlICEgTG9va2luZyBhdCB0aGUgcGF0Y2ggaXQgc2VlbXMKPiA+ID4geW91 IHdhbnQgdG8gaGF2ZSB5b3VyIG93biBwaW4gY291bnQganVzdCBmb3IgS1ZNLiBUaGlzIGlzIGJh ZCwgd2UgYXJlCj4gPiA+IGFscmVhZHkgdHJ5aW5nIHRvIHNvbHZlIHRoZSBHVVAgdGhpbmcgKHNl ZSBhbGwgdmFyaW91cyBwYXRjaHNldCBhYm91dAo+ID4gPiBHVVAgcG9zdGVkIHJlY2VudGx5KS4K PiA+ID4KPiA+ID4gWW91IG5lZWQgdG8gcmV0aGluayBob3cgeW91IHdhbnQgdG8gYWNoaWV2ZSB0 aGlzLiBXaHkgbm90IHNpbXBseSBhCj4gPiA+IHJlbW90ZSByZWFkKCkvd3JpdGUoKSBpbnRvIHRo ZSBwcm9jZXNzIG1lbW9yeSBpZSBLVk1JIHdvdWxkIGNhbGwgYW4KPiA+ID4gaW9jdGwgdGhhdCBh bGxvdyB0byByZWFkIG9yIHdyaXRlIGludG8gYSByZW1vdGUgcHJvY2VzcyBtZW1vcnkgbGlrZQo+ ID4gPiBwdHJhY2UoKSBidXQgb24gc3Rlcm9pZCAuLi4KPiA+ID4KPiA+ID4gQWRkaW5nIHRoaXMg d2hvbGUgYmlnIGNvbXBsZXggaW5mcmFzdHJ1Y3R1cmUgd2l0aG91dCBqdXN0aWZpY2F0aW9uIG9m Cj4gPiA+IHdoeSB3ZSBuZWVkIHRvIGF2b2lkIHJvdW5kIHRyaXAgaXMganVzdCB0b28gbXVjaCBy ZWFsbHkuCj4gPiAKPiA+IFRoaW5raW5nIGEgYml0IG1vcmUgYWJvdXQgdGhpcywgeW91IGNhbiBh Y2hpZXZlIHRoZSBzYW1lIHRoaW5nIHdpdGhvdXQKPiA+IGFkZGluZyBhIHNpbmdsZSBsaW5lIHRv IGFueSBtbSBjb2RlLiBJbnN0ZWFkIG9mIGhhdmluZyBtbWFwIHdpdGgKPiA+IFBST1RfTk9ORSB8 IE1BUF9MT0NLRUQgeW91IGhhdmUgdXNlcnNwYWNlIG1tYXAgc29tZSBrdm0gZGV2aWNlCj4gPiBm aWxlIChpIGFtIGFzc3VtaW5nIHRoaXMgaXMgc29tZXRoaW5nIHlvdSBhbHJlYWR5IGhhdmUgYW5k IGNhbiBjb250cm9sIHRoZQo+ID4gbW1hcCBjYWxsYmFjaykuCj4gPiAKPiA+IFNvIG5vdyBrZXJu ZWwgc2lkZSB5b3UgaGF2ZSBhIHZtYSB3aXRoIGEgdm1fb3BlcmF0aW9uc19zdHJ1Y3QgdW5kZXIg eW91cgo+ID4gY29udHJvbCB0aGlzIG1lYW5zIHRoYXQgZXZlcnl0aGluZyB5b3Ugd2FudCB0byBi bG9jayBtbSB3aXNlIGZyb20gd2l0aGluCj4gPiB0aGUgaW5zcGVjdG9yIHByb2Nlc3MgY2FuIGJl IGJsb2NrIHRocm91Z2ggdGhvc2UgY2FsbC0gYmFja3MKPiA+IChmaW5kX3NwZWNpYWxfcGFnZSgp IHNwZWNpZmljYWx5IGZvciB3aGljaCB5b3UgaGF2ZSB0byByZXR1cm4gTlVMTCBhbGwgdGhlCj4g PiB0aW1lKS4KPiA+IAo+ID4gVG8gbWlycm9yIHRhcmdldCBwcm9jZXNzIG1lbW9yeSB5b3UgY2Fu IHVzZSBobW1fbWlycm9yLCB3aGVuIHlvdQo+ID4gcG9wdWxhdGUgdGhlIGluc3BlY3RvciBwcm9j ZXNzIHBhZ2UgdGFibGUgeW91IHVzZSBpbnNlcnRfcGZuKCkgKG1tYXAgb2YKPiA+IHRoZSBrdm0g ZGV2aWNlIGZpbGUgbXVzdCBtYXJrIHRoaXMgdm1hIGFzIFBGTk1BUCkuCj4gPiAKPiA+IEJ5IGZv bGxvd2luZyB0aGUgaG1tX21pcnJvciBBUEksIGFueXRpbWUgdGhlIHRhcmdldCBwcm9jZXNzIGhh cyBhIGNoYW5nZSBpbgo+ID4gaXRzIHBhZ2UgdGFibGUgKGllIHZpcnR1YWwgYWRkcmVzcyAtPiBw YWdlKSB5b3Ugd2lsbCBnZXQgYSBjYWxsYmFjayBhbmQgYWxsIHlvdQo+ID4gaGF2ZSB0byBkbyBp cyBjbGVhciB0aGUgcGFnZSB0YWJsZSB3aXRoaW4gdGhlIGluc3BlY3RvciBwcm9jZXNzIGFuZCBm bHVzaCB0bGIKPiA+ICh1c2UgemFwX3BhZ2VfcmFuZ2UpLgo+ID4gCj4gPiBPbiBwYWdlIGZhdWx0 IHdpdGhpbiB0aGUgaW5zcGVjdG9yIHByb2Nlc3MgdGhlIGZhdWx0IGNhbGxiYWNrIG9mIHZtX29w cyB3aWxsCj4gPiBnZXQgY2FsbCBhbmQgZnJvbSB0aGVyZSB5b3UgY2FsbCBobW1fbWlycm9yIGZv bGxvd2luZyBpdHMgQVBJLgo+ID4gCj4gPiBPaCBhbHNvIG1hcmsgdGhlIHZtYSB3aXRoIFZNX1dJ UEVPTkZPUksgdG8gYXZvaWQgYW55IGlzc3VlIGlmIHRoZQo+ID4gaW5zcGVjdG9yIHByb2Nlc3Mg dXNlIGZvcmsoKSAoeW91IGNvdWxkIHN1cHBvcnQgZm9yayBidXQgdGhlbiB5b3Ugd291bGQKPiA+ IG5lZWQgdG8gbWFyayB0aGUgdm1hIGFzIFNIQVJFRCBhbmQgdXNlIHVubWFwX21hcHBpbmdfcGFn ZXMgaW5zdGVhZCBvZgo+ID4gemFwX3BhZ2VfcmFuZ2UpLgo+ID4gCj4gPiAKPiA+IFRoZXJlIGV2 ZXJ5dGhpbmcgeW91IHdhbnQgdG8gZG8gd2l0aCBhbHJlYWR5IHVwc3RyZWFtIG1tIGNvZGUuCj4g Cj4gSSdtIHRoZSBhdXRob3Igb2YgcmVtb3RlIG1hcHBpbmcsIHNvIEkgb3dlIGV2ZXJ5Ym9keSBz b21lIGV4cGxhbmF0aW9ucy4KPiBNeSByZXF1aXJlbWVudCB3YXMgdG8gbWFwIHBhZ2VzIGZyb20g b25lIFFFTVUgcHJvY2VzcyB0byBhbm90aGVyIFFFTVUgCj4gcHJvY2VzcyAob3VyIGluc3BlY3Rv ciBwcm9jZXNzIHdvcmtzIGluIGEgdmlydHVhbCBtYWNoaW5lIG9mIGl0cyBvd24pLiBTbyBJIGhh ZCAKPiB0byBpbXBsZW1lbnQgYSBLU00tbGlrZSBwYWdlIHNoYXJpbmcgYmV0d2VlbiBwcm9jZXNz ZXMsIHdoZXJlIGFuIGFub24gcGFnZQo+IGZyb20gdGhlIHRhcmdldCBRRU1VJ3Mgd29ya2luZyBt ZW1vcnkgaXMgcHJvbW90ZWQgdG8gYSByZW1vdGUgcGFnZSBhbmQgCj4gbWFwcGVkIGluIHRoZSBp bnNwZWN0b3IgUUVNVSdzIHdvcmtpbmcgbWVtb3J5IChib3RoIGFub24gVk1BcykuIAo+IFRoZSBl eHRyYSBwYWdlIGZsYWcgaXMgZm9yIGRpZmZlcmVudGlhdGluZyB0aGUgcGFnZSBmb3Igcm1hcCB3 YWxraW5nLgo+IAo+IFRoZSBtYXBwaW5nIHJlcXVlc3RzIGNvbWUgYXQgUEFHRV9TSVpFIGdyYW51 bGFyaXR5IGZvciByYW5kb20gYWRkcmVzc2VzIAo+IHdpdGhpbiB0aGUgdGFyZ2V0L2luc3BlY3Rv ciBRRU1Vcywgc28gSSBjb3VsZG4ndCBkbyBhbnkgbGluZWFyIG1hcHBpbmcgdGhhdAo+IHdvdWxk IGtlZXAgdGhpbmdzIHNpbXBsZXIuIAo+IAo+IEkgaGF2ZSBhbiBleHRyYSBwYXRjaCB0aGF0IGRv ZXMgcmVtb3RlIG1hcHBpbmcgYnkgbWlycm9yaW5nIGFuIGVudGlyZSBWTUEKPiBmcm9tIHRoZSB0 YXJnZXQgcHJvY2VzcyBieSB3YXkgb2YgYSBkZXZpY2UgZmlsZS4gVGhpcyB0aGluZyBjcmVhdGVz IGEgc2VwYXJhdGUgCj4gbWlycm9yIFZNQSBpbiBteSBpbnNwZWN0b3IgcHJvY2VzcyAoYXQgdGhl IG1vbWVudCBhIFFFTVUpLCBidXQgdGhlbiBJIAo+IGJ1bXBlZCBpbnRvIHRoZSBLVk0gaHZhLT5n cGEgbWFwcGluZywgd2hpY2ggbWFrZXMgaXQgaGFyZCB0byBvdmVycmlkZSAKPiBtYXBwaW5ncyB3 aXRoIGFkZHJlc3NlcyBvdXRzaWRlIG1lbXNsb3QgYXNzb2NpYXRlZCBWTUFzLgoKTm90IHN1cmUg aSB1bmRlcnN0YW5kLCB5b3UgYXJlIHNheWluZyB0aGF0IHRoZSBzb2x1dGlvbiBpIG91dGxpbmUg YWJvdmUKZG9lcyBub3Qgd29yayA/IElmIHNvIHRoZW4gaSB0aGluayB5b3UgYXJlIHdyb25nLCBp biB0aGUgYWJvdmUgc29sdXRpb24KdGhlIGltcG9ydGluZyBwcm9jZXNzIG1tYXAgYSBkZXZpY2Ug ZmlsZSBhbmQgdGhlIHJlc3VsdGluZyB2bWEgaXMgdGhlbgpwb3B1bGF0ZWQgdXNpbmcgaW5zZXJ0 X3BmbigpIGFuZCBjb25zdGFudGx5IGtlZXAgc3luY2hyb25pemUgd2l0aCB0aGUKdGFyZ2V0IHBy b2Nlc3MgdGhyb3VnaCBtaXJyb3Jpbmcgd2hpY2ggbWVhbnMgdGhhdCB5b3UgbmV2ZXIgaGF2ZSB0 byBsb29rCmF0IHRoZSBzdHJ1Y3QgcGFnZSAuLi4geW91IGNhbiBtaXJyb3IgYW55IGtpbmQgb2Yg bWVtb3J5IGZyb20gdGhlIHJlbW90ZQpwcm9jZXNzLgoKQW0gaSBtaXNzLXVuZGVyc3RhbmRpbmcg c29tZXRoaW5nIGhlcmUgPwoKQ2hlZXJzLApKw6lyw7RtZQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpWaXJ0dWFsaXphdGlvbiBtYWlsaW5nIGxpc3QKVmly dHVhbGl6YXRpb25AbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0cy5saW51 eGZvdW5kYXRpb24ub3JnL21haWxtYW4vbGlzdGluZm8vdmlydHVhbGl6YXRpb24= 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 4D85EC43331 for ; Thu, 5 Sep 2019 18:10:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 491AC206BA for ; Thu, 5 Sep 2019 18:10:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729782AbfIESKD (ORCPT ); Thu, 5 Sep 2019 14:10:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49592 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726837AbfIESKC (ORCPT ); Thu, 5 Sep 2019 14:10:02 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0961315C009; Thu, 5 Sep 2019 18:10:01 +0000 (UTC) Received: from redhat.com (unknown [10.20.6.178]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 925325D6A3; Thu, 5 Sep 2019 18:09:57 +0000 (UTC) Date: Thu, 5 Sep 2019 14:09:55 -0400 From: Jerome Glisse To: Mircea CIRJALIU - MELIU Cc: Adalbert =?utf-8?B?TGF6xINy?= , Matthew Wilcox , "kvm@vger.kernel.org" , "linux-mm@kvack.org" , "virtualization@lists.linux-foundation.org" , Paolo Bonzini , 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: <20190905180955.GA3251@redhat.com> References: <20190809160047.8319-1-alazar@bitdefender.com> <20190809160047.8319-72-alazar@bitdefender.com> <20190809162444.GP5482@bombadil.infradead.org> <1565694095.D172a51.28640.@15f23d3a749365d981e968181cce585d2dcb3ffa> <20190815191929.GA9253@redhat.com> <20190815201630.GA25517@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Thu, 05 Sep 2019 18:10:02 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Aug 23, 2019 at 12:39:21PM +0000, Mircea CIRJALIU - MELIU wrote: > > On Thu, Aug 15, 2019 at 03:19:29PM -0400, Jerome Glisse wrote: > > > On Tue, Aug 13, 2019 at 02:01:35PM +0300, Adalbert Lazăr wrote: > > > > On Fri, 9 Aug 2019 09:24:44 -0700, Matthew Wilcox > > wrote: > > > > > On Fri, Aug 09, 2019 at 07:00:26PM +0300, Adalbert Lazăr wrote: > > > > > > +++ b/include/linux/page-flags.h > > > > > > @@ -417,8 +417,10 @@ PAGEFLAG(Idle, idle, PF_ANY) > > > > > > */ > > > > > > #define PAGE_MAPPING_ANON 0x1 > > > > > > #define PAGE_MAPPING_MOVABLE 0x2 > > > > > > +#define PAGE_MAPPING_REMOTE 0x4 > > > > > > > > > > Uh. How do you know page->mapping would otherwise have bit 2 > > clear? > > > > > Who's guaranteeing that? > > > > > > > > > > This is an awfully big patch to the memory management code, buried > > > > > in the middle of a gigantic series which almost guarantees nobody > > > > > would look at it. I call shenanigans. > > > > > > > > > > > @@ -1021,7 +1022,7 @@ void page_move_anon_rmap(struct page > > *page, struct vm_area_struct *vma) > > > > > > * __page_set_anon_rmap - set up new anonymous rmap > > > > > > * @page: Page or Hugepage to add to rmap > > > > > > * @vma: VM area to add page to. > > > > > > - * @address: User virtual address of the mapping > > > > > > + * @address: User virtual address of the mapping > > > > > > > > > > And mixing in fluff changes like this is a real no-no. Try again. > > > > > > > > > > > > > No bad intentions, just overzealous. > > > > I didn't want to hide anything from our patches. > > > > Once we advance with the introspection patches related to KVM we'll > > > > be back with the remote mapping patch, split and cleaned. > > > > > > They are not bit left in struct page ! Looking at the patch it seems > > > you want to have your own pin count just for KVM. This is bad, we are > > > already trying to solve the GUP thing (see all various patchset about > > > GUP posted recently). > > > > > > You need to rethink how you want to achieve this. Why not simply a > > > remote read()/write() into the process memory ie KVMI would call an > > > ioctl that allow to read or write into a remote process memory like > > > ptrace() but on steroid ... > > > > > > Adding this whole big complex infrastructure without justification of > > > why we need to avoid round trip is just too much really. > > > > Thinking a bit more about this, you can achieve the same thing without > > adding a single line to any mm code. Instead of having mmap with > > PROT_NONE | MAP_LOCKED you have userspace mmap some kvm device > > file (i am assuming this is something you already have and can control the > > mmap callback). > > > > So now kernel side you have a vma with a vm_operations_struct under your > > control this means that everything you want to block mm wise from within > > the inspector process can be block through those call- backs > > (find_special_page() specificaly for which you have to return NULL all the > > time). > > > > To mirror target process memory you can use hmm_mirror, when you > > populate the inspector process page table you use insert_pfn() (mmap of > > the kvm device file must mark this vma as PFNMAP). > > > > By following the hmm_mirror API, anytime the target process has a change in > > its page table (ie virtual address -> page) you will get a callback and all you > > have to do is clear the page table within the inspector process and flush tlb > > (use zap_page_range). > > > > On page fault within the inspector process the fault callback of vm_ops will > > get call and from there you call hmm_mirror following its API. > > > > Oh also mark the vma with VM_WIPEONFORK to avoid any issue if the > > inspector process use fork() (you could support fork but then you would > > need to mark the vma as SHARED and use unmap_mapping_pages instead of > > zap_page_range). > > > > > > There everything you want to do with already upstream mm code. > > I'm the author of remote mapping, so I owe everybody some explanations. > My requirement was to map pages from one QEMU process to another QEMU > process (our inspector process works in a virtual machine of its own). So I had > to implement a KSM-like page sharing between processes, where an anon page > from the target QEMU's working memory is promoted to a remote page and > mapped in the inspector QEMU's working memory (both anon VMAs). > The extra page flag is for differentiating the page for rmap walking. > > The mapping requests come at PAGE_SIZE granularity for random addresses > within the target/inspector QEMUs, so I couldn't do any linear mapping that > would keep things simpler. > > I have an extra patch that does remote mapping by mirroring an entire VMA > from the target process by way of a device file. This thing creates a separate > mirror VMA in my inspector process (at the moment a QEMU), but then I > bumped into the KVM hva->gpa mapping, which makes it hard to override > mappings with addresses outside memslot associated VMAs. 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. Am i miss-understanding something here ? Cheers, Jérôme