From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeJvn-0003dd-E0 for qemu-devel@nongnu.org; Fri, 11 Mar 2016 05:04:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeJvk-0001fM-OG for qemu-devel@nongnu.org; Fri, 11 Mar 2016 05:04:27 -0500 References: <1447201710-10229-1-git-send-email-benh@kernel.crashing.org> <1447201710-10229-73-git-send-email-benh@kernel.crashing.org> <56D74D5E.9090307@redhat.com> <56E081E1.5020003@fr.ibm.com> <56E092DE.5040101@redhat.com> <56E1B665.5040909@redhat.com> <56E1F4E9.5050307@fr.ibm.com> From: Thomas Huth Message-ID: <56E29820.5000500@redhat.com> Date: Fri, 11 Mar 2016 11:04:16 +0100 MIME-Version: 1.0 In-Reply-To: <56E1F4E9.5050307@fr.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 72/77] ppc: A couple more dummy POWER8 Book4 regs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-ppc@nongnu.org Cc: qemu-devel@nongnu.org On 10.03.2016 23:27, C=C3=A9dric Le Goater wrote: > On 03/10/2016 07:01 PM, Thomas Huth wrote: >> On 09.03.2016 22:17, Thomas Huth wrote: >>> On 09.03.2016 21:04, C=C3=A9dric Le Goater wrote: >> .... >>>> I have been maintaining a port of Ben's patchset on the latest qemu = for other=20 >>>> parts which should come after pnv is merged so I have a framework to= test such=20 >>>> sub-patchsets. I also have time to work on them but clearly not the = expertise >>>> in all areas ! >>> >>> That would be great if you could take care of this! >>> >>>> What would be nice is to identify the most obvious ones, non controv= ersial >>>> that could be merged after a few iterations. I have a vague idea, th= e ones=20 >>>> Reviewed-by David obviously being good candidates, the definition of= new SPRs=20 >>>> (even the dummy ones ?). >>> >>> I really like to see the KVM SPRs patches first - since they are fixi= ng >>> potential problems with migration of the _current_ KVM machines alrea= dy! >>> And being bug fixes, maybe these patches could even be included for Q= EMU >>> 2.6 already? (i.e. before the hard freeze at the end of March) >>> >>> So my wish-list for a first small patch series looks like this: >>> >>> 5b287e66c7513209 ppc: Add macros to register hypervisor mode SPRs >>> 34f1af75e75e7ba0 ppc: Add dummy CIABR SPR >>> 48adf38e9cab4663 ppc: A couple more dummy POWER8 Book4 regs >>> 730a9b4dc9414818 ppc: Add KVM numbers to some P8 SPRs >>> >>> There are a couple of other patches touching the SPRs initialization, >>> but they are not important with regards to migration... so not sure >>> whether it makes sense to include them now already... >> >> FWIW, I just saw today (by doing some more experiments with >> kvm-unit-tests) that the IAMR register is also not migrated yet ... so >> it would be nice if you could include the related patches for IAMR, to= o, >> and wire the KVM part up with KVM_REG_PPC_IAMR... >=20 > OK. So we should be targeting something like : >=20 > ppc: Update SPR definitions > ppc: Add macros to register hypervisor mode SPRs > ppc: Add a bunch of hypervisor SPRs to Book3s >=20 > ppc: LPCR is a HV resource > ppc: SPURR & PURR are HV writeable and privileged > ppc: Add dummy SPR_IC for POWER8 > ppc: Initialize AMOR in PAPR mode > ppc: Fix writing to AMR/UAMOR > ppc: Add POWER8 IAMR register > ppc: Add a few more P8 PMU SPRs > ppc: Add dummy write to VTB > ppc: Add dummy POWER8 MPPR register > ppc: Add dummy POWER8 PSPB SPR > ppc: Add dummy CIABR SPR > ppc: Add dummy ACOP SPR > ppc: A couple more dummy POWER8 Book4 regs > ppc: Add KVM numbers to some P8 SPRs Sounds good - but you likely can drop the "Add a few more P8 PMU SPRs" from your list since it has already been queued by David already (see https://github.com/dgibson/qemu/commits/ppc-for-2.6), and the PSPB patch is also not required anymore since I submitted a similar patch to David already when I discovered that it is lost during migration. > Also, there seem to be an issue with qemu's HEAD on ppc64el with the > random device : >=20 > -object rng-random,filename=3D/dev/urandom,id=3Dgid0 -device spapr-rng= ,rng=3Dgid0 >=20 > qemu "hangs". This is a vague description for a symptom ... Does that r= ing > a bell or do I need to dig in to get more info ?=20 Works for me=E2=84=A2 ... could you supply more information? Where does i= t hang? Which exact level of QEMU are you using? ... and please open a new mail thread for this, since it's off-topic to this mail thread. Thomas