From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 81540211F2828 for ; Mon, 11 Jun 2018 22:40:50 -0700 (PDT) Message-ID: <1528810024.3385.15.camel@linux.intel.com> Subject: Re: [Qemu-devel] [RFC PATCH 1/1] nvdimm: let qemu requiring section alignment of pmem resource. From: "Zhang,Yi" Date: Tue, 12 Jun 2018 21:27:04 +0800 In-Reply-To: References: <20180611162630.GH17756@stefanha-x1.localdomain> Mime-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams , Stefan Hajnoczi Cc: Xiao Guangrong , linux-nvdimm , "Michael S. Tsirkin" , Qemu Developers , Igor Mammedov , Eduardo Habkost List-ID: T24g5LiALCAyMDE4LTA2LTExIGF0IDE5OjU1IC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6Cj4g T24gTW9uLCBKdW4gMTEsIDIwMTggYXQgOToyNiBBTSwgU3RlZmFuIEhham5vY3ppIDxzdGVmYW5o YUByZWRoYXQuY29tCj4gPiB3cm90ZToKPiA+IAo+ID4gT24gTW9uLCBKdW4gMTEsIDIwMTggYXQg MDY6NTQ6MjVQTSArMDgwMCwgWmhhbmcgWWkgd3JvdGU6Cj4gPiA+IAo+ID4gPiBOdmRpbW0gZHJp dmVyIHVzZSBNZW1vcnkgaG90LXBsdWcgQVBJcyB0byBtYXAgaXQncyBwbWVtIHJlc291cmNlLAo+ ID4gPiB3aGljaCBhdCBhIHNlY3Rpb24gZ3JhbnVsYXJpdHkuCj4gPiA+IAo+ID4gPiBXaGVuIFFF TVUgZW11bGF0ZWQgdGhlIHZOVkRJTU0gZGV2aWNlLCBkZWNyZWFzZSB0aGUgbGFiZWwtCj4gPiA+ IHN0b3JhZ2UsCj4gPiA+IFFFTVUgd2lsbCBwdXQgdGhlIHZOVkRJTU1zIGRpcmVjdGx5IG5leHQg dG8gb25lIGFub3RoZXIgaW4KPiA+ID4gcGh5c2ljYWwKPiA+ID4gYWRkcmVzcyBzcGFjZSwgd2hp Y2ggbWVhbnMgdGhhdCB0aGUgYm91bmRhcnkgYmV0d2VlbiB0aGVtIHdvbid0Cj4gPiA+IGFsaWdu IHRvIHRoZSAxMjggTUIgbWVtb3J5IHNlY3Rpb24gc2l6ZS4KPiA+IEknbSBoYXZpbmcgYSBoYXJk IHRpbWUgcGFyc2luZyB0aGlzLgo+ID4gCj4gPiBXaGVyZSBkb2VzIHRoZSAiMTI4IE1CIG1lbW9y eSBzZWN0aW9uIHNpemUiIGNvbWUgZnJvbT/CoMKgQUNQST8KPiA+IEEgY2hpcHNldC1zcGVjaWZp YyB2YWx1ZT8KPiA+IAo+IFRoZSBkZXZtX21lbXJlbWFwX3BhZ2VzKCkgaW1wbGVtZW50YXRpb24g dXNlIHRoZSBtZW1vcnkgaG90cGx1ZyBjb3JlCj4gdG8gYWxsb2NhdGUgdGhlICdzdHJ1Y3QgcGFn ZScgYXJyYXkvbWFwIGZvciBwZXJzaXN0ZW50IG1lbW9yeS4gTWVtb3J5Cj4gaG90cGx1ZyBjYW4g b25seSBiZSBwZXJmb3JtZWQgaW4gdGVybXMgb2Ygc2VjdGlvbnMsIDEyOE1CIG9uIHg4Nl82NC4K PiBUaGVyZSBpcyBzb21lIGxpbWl0ZWQgc3VwcG9ydCBmb3IgYWxsb3dpbmcgZGV2bV9tZW1yZW1h cF9wYWdlcygpIHRvCj4gb3ZlcmxhcCAnU3lzdGVtIFJBTScgd2l0aGluIGEgZ2l2ZW4gc2VjdGlv biwgYnV0IGl0IGRvZXMgbm90Cj4gY3VycmVudGx5Cj4gc3VwcG9ydCBtdWx0aXBsZSBkZXZtX21l bXJlbWFwX3BhZ2VzKCkgY2FsbHMgb3ZlcmxhcHBpbmcgd2l0aGluIHRoZQo+IHNhbWUgc2VjdGlv bi4gVGhlcmUgaXMgY3VycmVudGx5IGEga2VybmVsIGJ1ZyB3aGVyZSB3ZSBkbyBub3QgaGFuZGxl Cj4gdGhpcyB1bnN1cHBvcnRlZCBjb25maWd1cmF0aW9uIGdyYWNlZnVsbHkuIFRoZSBmaXggd2ls bCBjYXVzZQo+IGNvbmZpZ3VyYXRpb25zIGNvbmZpZ3VyYXRpb25zIHRoYXQgdHJ5IHRvIG92ZXJs YXAgMiBwZXJzaXN0ZW50IG1lbW9yeQo+IHJhbmdlcyBpbiB0aGUgc2FtZSBzZWN0aW9uIHRvIGZh aWwuCj4gCj4gVGhlIHByb3Bvc2VkIGZpeCBpcyB0cnlpbmcgdG8gbWFrZSBzdXJlIHRoYXQgUUVN VSBkb2VzIG5vdCBydW4gYWZvdWwKPiBvZiB0aGlzIGNvbnN0cmFpbnQuCj4gCj4gVGhlcmUgaXMg Y3VycmVudGx5IG5vIGxpbmUgb2Ygc2lnaHQgdG8gcmVkdWNlIHRoZSBtaW5pbXVtIG1lbW9yeQo+ IGhvdHBsdWcgYWxpZ25tZW50IHNpemUgdG8gbGVzcyB0aGFuIDEyOE0uIEFsc28sIGFzIG90aGVy Cj4gYXJjaGl0ZWN0dXJlcwo+IG91dHNpZGUgb2YgeDg2XzY0IGFkZCBkZXZtX21lbXJlbWFwX3Bh Z2VzKCkgc3VwcG9ydCwgdGhlIG1pbmltdW0KPiBzZWN0aW9uIGFsaWdubWVudCBjb25zdHJhaW50 IG1pZ2h0IGNoYW5nZSBhbmQgaXMgYSBwcm9wZXJ0eSBvZiBhCj4gZ3Vlc3QKPiBPUy4gTXkgdW5k ZXJzdGFuZGluZyBpcyB0aGF0IHNvbWUgZ3Vlc3QgT1NlcyBtaWdodCBleHBlY3QgYW4gZXZlbgo+ IGxhcmdlciBwZXJzaXN0ZW50IG1lbW9yeSBtaW5pbXVtIGFsaWdubWVudC4KPiAKVGhhbmtzIERh bidzIGV4cGxhbmF0aW9uLCBJIHN0aWxsIGhhdmUgYSBxdWVzdGlvbiB0aGF0IHdoeSB3ZQpvdmVy bGFwcGluZwp0aGUgdW4tYWxpZ24gYXJlYSDCoGluc3RlYWQgb2YgZHJvcCBpdD8gYW5kIGxldCBp dCBhbGlnbiB0byB0aGUgbmV4dApzZWN0aW9uLsKgCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpMaW51eC1udmRpbW0gbWFpbGluZyBsaXN0CkxpbnV4LW52 ZGltbUBsaXN0cy4wMS5vcmcKaHR0cHM6Ly9saXN0cy4wMS5vcmcvbWFpbG1hbi9saXN0aW5mby9s aW51eC1udmRpbW0K From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSc3S-0007jY-DX for qemu-devel@nongnu.org; Tue, 12 Jun 2018 01:41:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fSc3N-0001kQ-H9 for qemu-devel@nongnu.org; Tue, 12 Jun 2018 01:41:18 -0400 Received: from mga17.intel.com ([192.55.52.151]:3730) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fSc3N-0001ZK-84 for qemu-devel@nongnu.org; Tue, 12 Jun 2018 01:41:13 -0400 Message-ID: <1528810024.3385.15.camel@linux.intel.com> From: "Zhang,Yi" Date: Tue, 12 Jun 2018 21:27:04 +0800 In-Reply-To: References: <20180611162630.GH17756@stefanha-x1.localdomain> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC PATCH 1/1] nvdimm: let qemu requiring section alignment of pmem resource. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dan Williams , Stefan Hajnoczi Cc: Xiao Guangrong , "Michael S. Tsirkin" , linux-nvdimm , Qemu Developers , yu.c.zhang@linux.intel.com, Igor Mammedov , Ross Zwisler , Eduardo Habkost On 一, 2018-06-11 at 19:55 -0700, Dan Williams wrote: > On Mon, Jun 11, 2018 at 9:26 AM, Stefan Hajnoczi > wrote: > > > > On Mon, Jun 11, 2018 at 06:54:25PM +0800, Zhang Yi wrote: > > > > > > Nvdimm driver use Memory hot-plug APIs to map it's pmem resource, > > > which at a section granularity. > > > > > > When QEMU emulated the vNVDIMM device, decrease the label- > > > storage, > > > QEMU will put the vNVDIMMs directly next to one another in > > > physical > > > address space, which means that the boundary between them won't > > > align to the 128 MB memory section size. > > I'm having a hard time parsing this. > > > > Where does the "128 MB memory section size" come from?  ACPI? > > A chipset-specific value? > > > The devm_memremap_pages() implementation use the memory hotplug core > to allocate the 'struct page' array/map for persistent memory. Memory > hotplug can only be performed in terms of sections, 128MB on x86_64. > There is some limited support for allowing devm_memremap_pages() to > overlap 'System RAM' within a given section, but it does not > currently > support multiple devm_memremap_pages() calls overlapping within the > same section. There is currently a kernel bug where we do not handle > this unsupported configuration gracefully. The fix will cause > configurations configurations that try to overlap 2 persistent memory > ranges in the same section to fail. > > The proposed fix is trying to make sure that QEMU does not run afoul > of this constraint. > > There is currently no line of sight to reduce the minimum memory > hotplug alignment size to less than 128M. Also, as other > architectures > outside of x86_64 add devm_memremap_pages() support, the minimum > section alignment constraint might change and is a property of a > guest > OS. My understanding is that some guest OSes might expect an even > larger persistent memory minimum alignment. > Thanks Dan's explanation, I still have a question that why we overlapping the un-align area  instead of drop it? and let it align to the next section.