From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOtkb-0005J9-Sn for qemu-devel@nongnu.org; Thu, 28 Jan 2016 16:05:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOtkY-0006Jk-Kl for qemu-devel@nongnu.org; Thu, 28 Jan 2016 16:05:09 -0500 References: <1453095881-16704-1-git-send-email-david@gibson.dropbear.id.au> <20160119074817.GA16048@in.ibm.com> <20160119110233.GE27454@voom.redhat.com> From: Alexander Graf Message-ID: <56AA827A.2070905@suse.de> Date: Thu, 28 Jan 2016 22:04:58 +0100 MIME-Version: 1.0 In-Reply-To: <20160119110233.GE27454@voom.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/3] Draft implementation of HPT resizing (qemu side) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , Bharata B Rao Cc: lvivier@redhat.com, thuth@redhat.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, paulus@samba.org On 01/19/2016 12:02 PM, David Gibson wrote: > On Tue, Jan 19, 2016 at 01:18:17PM +0530, Bharata B Rao wrote: >> On Mon, Jan 18, 2016 at 04:44:38PM +1100, David Gibson wrote: >>> Here is a draft qemu implementation of my proposed PAPR extension for >>> allowing runtime resizing of a KVM/ppc64 guest's hash page table. >>> That in turn will allow for more flexible memory hotplug. >>> >>> This should work with the guest kernel side patches I also posted >>> recently [1]. >>> >>> Still required to make this into a full implementation: >>> * Guest needs to auto-resize HPT on memory hotplug events >>> >>> * qemu needs to allocate HPT size based on current rather than >>> maximum memory if the guest is HPT resize aware >>> >>> * KVM host side implementation >>> >>> * PAPR standardization >> So with the current patchset (QEMU and guest kernel changes), I should >> be able to change the HTAB size of a PR guest right ? I see the below >> failure though: > Uh.. to be honest I haven't really considered the KVM case at all. > I'm kind of surprised it didn't just refuse to do anything. > >> [root@localhost ~]# cat /sys/kernel/debug/powerpc/pft-size >> 24 >> [root@localhost ~]# echo 26 > /sys/kernel/debug/powerpc/pft-size >> [ 65.996845] lpar: Attempting to resize HPT to shift 26 >> [ 65.996845] lpar: Attempting to resize HPT to shift 26 >> [ 66.113596] lpar: HPT resize to shift 26 complete (109 ms / 6 ms) >> [ 66.113596] lpar: HPT resize to shift 26 complete (109 ms / 6 ms) >> >> PR guest just hangs here while I see tons of below messages in >> the 1st level guest: >> >> KVM can't copy data from 0x3fff99e91400! >> ... >> Couldn't emulate instruction 0x00000000 (op 0 xop 0) >> kvmppc_handle_exit_pr: emulation at 700 failed (00000000) > Hm, not sure why that's happening. At first I thought it was because > we weren't updating SDR1 with the address of the new htab, but that's > actually in there. Maybe the KVM PR code isn't rereading it after > initial VM startup. The KVM PR code doesn't care - it just rereads SDR1 on every pteg lookup ;). There's no caching at all. Of course, the guest needs to invalidate all pending tlb entries if they're now invalid. Does this work on real hardware? Say, a G5? Alex