From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aP0Kd-0000d1-MS for qemu-devel@nongnu.org; Thu, 28 Jan 2016 23:06:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aP0Ka-0002kC-EJ for qemu-devel@nongnu.org; Thu, 28 Jan 2016 23:06:47 -0500 Date: Fri, 29 Jan 2016 13:47:12 +1100 From: David Gibson Message-ID: <20160129024712.GG23043@voom.redhat.com> References: <1453095881-16704-1-git-send-email-david@gibson.dropbear.id.au> <20160119074817.GA16048@in.ibm.com> <20160119110233.GE27454@voom.redhat.com> <56AA827A.2070905@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PyMzGVE0NRonI6bs" Content-Disposition: inline In-Reply-To: <56AA827A.2070905@suse.de> 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: Alexander Graf Cc: lvivier@redhat.com, thuth@redhat.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Bharata B Rao , paulus@samba.org --PyMzGVE0NRonI6bs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 28, 2016 at 10:04:58PM +0100, Alexander Graf wrote: >=20 >=20 > 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. >=20 > The KVM PR code doesn't care - it just rereads SDR1 on every pteg lookup = ;). > There's no caching at all. Ok, no idea why it's not working then. I'll investigate when I get a chanc= e. > Of course, the guest needs to invalidate all pending tlb entries if they'= re > now invalid. >=20 > Does this work on real hardware? Say, a G5? As Paulus says it would be possible to do HPT resizing on real hardware, but the implementation I've done is specific to PAPR. And obviously qemu wouldn't be relevant to that case. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --PyMzGVE0NRonI6bs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWqtKwAAoJEGw4ysog2bOSeAEQALMD9wEgw+J7QOcNXoHBvSfm Pa9leixfApH96dDeAAuRDrvqGLeDl2pMnXbydbvUC23ZY2dz+WRAYmNC982HPQQq qd0gnv9rlaJPTULqRWgX/zD03EtKnrCbomn98CQA2rkMrINDJcIaT8cwgs5OiV2b vya5HurY2Nrxpq68djbK3AE/8QQZ7brCkAARcCgZVfHCUGf0YcoMjakBvlE/wzrS 9xE5FnTMBbu2Z7vIE/4gGrj8ntWQ+DmDHfVNgssV8PmKMhnun4m0or/sZ0ftAiuz 3UFtnoX7D+dgnLRKbE4c9xBkStIYd/zM7Bgy3VxpWsB+/zzqJ0rYclAAoUIgCHQx Q4ysRWpiAEb+dRVOdT1B8lKIa2z4R0y8JN00UXBhfsnBacd0aM68jdjlZELXLprC SPvxM1ATvygSKLoHa5uQ5avP37gKgQykT3feuHAdOhFwZh3lDHY5Jqi7KlAovbW9 N1G/d9FqrFuS18tAIv5k0x8ryh03idzH0XrCsbEMWjiZEd8wwnnbSKm1QNQCh830 HS1lhFoIs2TzjVhKfRiJZ2c2hRlGcDLIKKgxPos6cg2EHztV0n4//pvtc2ac8cuI plAV8Ws3iGo2WEnEHN71SkGH6+/cG50VjY70ChoSNrZ+Z/zEPJkQeXsIGG7R5Ug7 RiTAXa6kYgfhiGhl7fHb =nbG9 -----END PGP SIGNATURE----- --PyMzGVE0NRonI6bs--