From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Tue, 15 May 2012 17:17:43 +0000 Subject: Re: [PATCH v2] KVM: PPC: Book3S HV: Make the guest hash table size configurable Message-Id: <4FB28FB7.2050400@suse.de> List-Id: References: <20120504123253.GA19293@bloggs.ozlabs.ibm.com> In-Reply-To: <20120504123253.GA19293@bloggs.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Paul Mackerras Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org On 05/04/2012 02:32 PM, Paul Mackerras wrote: > This adds a new ioctl to enable userspace to control the size of the guest > hashed page table (HPT) and to clear it out when resetting the guest. > The KVM_PPC_ALLOCATE_HTAB ioctl is a VM ioctl and takes as its parameter > a pointer to a u32 containing the desired order of the HPT (log base 2 > of the size in bytes), which is updated on successful return to the > actual order of the HPT which was allocated. > > There must be no vcpus running at the time of this ioctl. To enforce > this, we now keep a count of the number of vcpus running in > kvm->arch.vcpus_running. > > If the ioctl is called when a HPT has already been allocated, we don't > reallocate the HPT but just clear it out. We first clear the > kvm->arch.rma_setup_done flag, which has two effects: (a) since we hold > the kvm->lock mutex, it will prevent any vcpus from starting to run until > we're done, and (b) it means that the first vcpu to run after we're done > will re-establish the VRMA if necessary. > > If userspace doesn't call this ioctl before running the first vcpu, the > kernel will allocate a default-sized HPT at that point. We do it then > rather than when creating the VM, as the code did previously, so that > userspace has a chance to do the ioctl if it wants. > > When allocating the HPT, we can allocate either from the kernel page > allocator, or from the preallocated pool. If userspace is asking for > a different size from the preallocated HPTs, we first try to allocate > using the kernel page allocator. Then we try to allocate from the > preallocated pool, and then if that fails, we try allocating decreasing > sizes from the kernel page allocator, down to the minimum size allowed > (256kB). Note that the kernel page allocator limits allocations to > 1<< CONFIG_FORCE_MAX_ZONEORDER pages, which by default corresponds to > 16MB (on 64-bit powerpc, at least). > > Signed-off-by: Paul Mackerras Thanks, applied to kvm-ppc-next. Alex