From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 4/4 v3] KVM: Introduce kvm_memory_slot::arch and move lpage_info into it Date: Wed, 07 Mar 2012 14:27:35 +0100 Message-ID: <4F576247.4010402@suse.de> References: <20120130124859.6c3bb19f.yoshikawa.takuya@oss.ntt.co.jp> <20120130125308.51e22f12.yoshikawa.takuya@oss.ntt.co.jp> <20120130143533.e52efcbe.yoshikawa.takuya@oss.ntt.co.jp> <4F274144.9000606@oss.ntt.co.jp> <065A8746-BEDD-4E2B-8AAB-FDA26D496582@suse.de> <20120307134617.f7fa887c.yoshikawa.takuya@oss.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org, cotte@de.ibm.com, Paul Mackerras , borntraeger@de.ibm.com, Andrea Arcangeli To: Takuya Yoshikawa Return-path: Received: from cantor2.suse.de ([195.135.220.15]:36512 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757854Ab2CGN1i (ORCPT ); Wed, 7 Mar 2012 08:27:38 -0500 In-Reply-To: <20120307134617.f7fa887c.yoshikawa.takuya@oss.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 03/07/2012 05:46 AM, Takuya Yoshikawa wrote: > Alexander Graf wrote: > >>>> This patch is the first step to make this difference clear by >>>> introducing kvm_memory_slot::arch; lpage_info is moved into it. >>> I am planning to move rmap stuff into arch next if this patch is accepted. >>> >>> Please let me know if you have some opinion about which members should be >>> moved into this. >> What is this lpage stuff? When do we need it? Right now the code gets executed on ppc, right? And with the patch it doesn't, no? > lpage_info is used for supporting huge pages on kvm-x86: we have > write_count and rmap_pde for each largepage and these are in lpage_info. > > At the time I made this patch, it seemed that only kvm-x86 supported > huge pages, on ppc the array should be empty: Hrm. I suppose this refers to transparent huge pages? Andrea, Paul, is there anything keeping is from also needing/using that logic? > /* We don't currently support large pages. */ > #define KVM_HPAGE_GFN_SHIFT(x) 0 > #define KVM_NR_PAGE_SIZES 1 > > How each architecture supports huge pages will differ a lot. > So this kind of memory consuming stuff should be arch specific. Yeah, probably. > IMO rmap also should to be moved into the arch. > s390 does not need it and other architectures than x86 will be happy if > the type of it can be changed from unsigned long to a pointer, no? How would an unsigned long make a difference over a pointer? Alex