From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8tJM-0003zx-Ll for qemu-devel@nongnu.org; Fri, 03 Jun 2016 13:55:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8tJI-0006ix-FB for qemu-devel@nongnu.org; Fri, 03 Jun 2016 13:55:07 -0400 Received: from 10.mo1.mail-out.ovh.net ([178.32.96.102]:41439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8tJI-0006in-5Z for qemu-devel@nongnu.org; Fri, 03 Jun 2016 13:55:04 -0400 Received: from player729.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 0DC3910880FC for ; Fri, 3 Jun 2016 19:55:01 +0200 (CEST) References: <1464955880-10176-1-git-send-email-clg@kaod.org> <57518BA1.1030400@ilande.co.uk> <57518D7C.50703@kaod.org> <57518EF7.3020200@free.fr> <575190C5.2040605@ilande.co.uk> <5751A6AE.60007@ilande.co.uk> From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Message-ID: <5751C462.8070600@kaod.org> Date: Fri, 3 Jun 2016 19:54:42 +0200 MIME-Version: 1.0 In-Reply-To: <5751A6AE.60007@ilande.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/3] ppc: complete the new HV mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland , David Gibson Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org On 06/03/2016 05:47 PM, Mark Cave-Ayland wrote: > On 03/06/16 15:14, Mark Cave-Ayland wrote: >=20 >> On 03/06/16 15:06, Cedric Le Goater wrote: >> >>> On 06/03/2016 04:00 PM, C=C3=A9dric Le Goater wrote: >>>> Hello Mark, >>>> >>>> On 06/03/2016 03:52 PM, Mark Cave-Ayland wrote: >>>>> On 03/06/16 13:11, C=C3=A9dric Le Goater wrote: >>>>> >>>>>> This is follow up to complete the serie "ppc: preparing pnv landin= g >>>>>> (round 2)" plus a little fix on instruction privileges. >>>>>> >>>>>> Tested on a POWER8 pserie guest and on mac99. >>>>>> >>>>>> Benjamin Herrenschmidt (2): >>>>>> ppc: Fix hreg_store_msr() so that non-HV mode cannot alter MSR:H= V >>>>>> ppc: Better figure out if processor has HV mode >>>>>> >>>>>> C=C3=A9dric Le Goater (1): >>>>>> ppc: fix hrfid, tlbia and slbia privilege >>>>>> >>>>>> target-ppc/cpu.h | 4 ++++ >>>>>> target-ppc/excp_helper.c | 8 ++++++-- >>>>>> target-ppc/helper_regs.h | 4 ++-- >>>>>> target-ppc/translate.c | 10 ++++++---- >>>>>> target-ppc/translate_init.c | 19 +++++++++++++++---- >>>>>> 5 files changed, 33 insertions(+), 12 deletions(-) >>>>> >>>>> Hi C=C3=A9dric, >>>>> >>>>> I can confirm that this patchset fixes starting up OpenBIOS for bot= h >>>>> g3beige/mac99 in my tests here. With the escc fix also applied, the= only >>>>> outstanding issue is the removal of the tlb_flush() statements whic= h >>>>> causes Darwin, MacOS X and HelenOS 0.60 to panic on boot >>>> >>>> Is that just booting the CDROM or the complete OS ? because I tried = that a=20 >>>> couple of time with ppc-for-2.7-20160531 + the three patches above a= nd=20 >>>> did not see the issue again. I reached the device selection prompt.=20 >>>> >>>> I must be doing something wrong.=20 >>> >>> I was using '-cpu 750' for some reason and this is why it succeeded. = It fails >>> without. We are getting close.=20 >> >> Hmmm that works for -M g3beige Darwin, but not HelenOS here. Although >> interestingly -M g3beige -m 256 seems to "fix" Darwin here too >> (presumably because the memory allocation routines can just allocate n= ew >> RAM rather than reusing existing RAM which may be cached in the TLB). >> >> What a strange coincidence that I've just posted a patch that fixes up >> the debugging in target-ppc/mmu_helper.c ;) >=20 > It also looks like you need my beta patch to convert the macio > controller over to using the DMA helpers here: > https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg04907.html. > At least that seems to progress things a little further on one of my > MacOS tests. >=20 > Looking at the DBDMA code I still see a few calls to > cpu_physical_memory_read() / cpu_physical_memory_write() scattered > around. Do these need to be switched over to dma_memory_read() / > dma_memory_write() in order to correctly invalidate the TLB upon write? I haven't had time to check your patches yet. I will give them a try in a= =20 couple of days.=20 Thanks, C.=20