From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIrfr-0003JV-Cy for qemu-devel@nongnu.org; Tue, 12 Jan 2016 00:39:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIrfp-0007rU-9B for qemu-devel@nongnu.org; Tue, 12 Jan 2016 00:39:19 -0500 Received: from mail-pa0-x243.google.com ([2607:f8b0:400e:c03::243]:32890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIrfp-0007rC-1W for qemu-devel@nongnu.org; Tue, 12 Jan 2016 00:39:17 -0500 Received: by mail-pa0-x243.google.com with SMTP id pv5so26394977pac.0 for ; Mon, 11 Jan 2016 21:39:16 -0800 (PST) References: <1450665670-18323-1-git-send-email-david@gibson.dropbear.id.au> <1450665670-18323-3-git-send-email-david@gibson.dropbear.id.au> <568F3352.9090306@ozlabs.ru> <20160112002609.GF22925@voom.redhat.com> <56948169.1000702@ozlabs.ru> <20160112043355.GT22925@voom.redhat.com> From: Alexey Kardashevskiy Message-ID: <56949177.8040309@ozlabs.ru> Date: Tue, 12 Jan 2016 16:39:03 +1100 MIME-Version: 1.0 In-Reply-To: <20160112043355.GT22925@voom.redhat.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] ppc: Allow 64kiB pages for POWER8 in TCG List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: lvivier@redhat.com, thuth@redhat.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, agraf@suse.de, qemu-ppc@nongnu.org On 01/12/2016 03:33 PM, David Gibson wrote: > On Tue, Jan 12, 2016 at 03:30:33PM +1100, Alexey Kardashevskiy wrote: >> On 01/12/2016 11:26 AM, David Gibson wrote: >>> On Fri, Jan 08, 2016 at 02:56:02PM +1100, Alexey Kardashevskiy wrote: >>>> On 12/21/2015 01:41 PM, David Gibson wrote: >>>>> Now that the spapr code has been extended to support 64kiB pages, we can >>>>> allow guests to use 64kiB pages on an emulated POWER8 by adding it to the >>>>> "segment_page_sizes" structure which is advertised via the device tree. >>>>> >>>>> For now we just add support for 64kiB pages in 64kiB page segments. Real >>>>> POWER8 also supports 64kiB pages in 4kiB page segments, but that will >>>>> require more work to implement. >>>>> >>>>> Real POWER7s (and maybe some other CPU models) also support 64kiB pages, >>>>> however, I don't want to add support there without double checking if they >>>>> use the same HPTE and SLB encodings (in principle these are implementation >>>>> dependent). >>>>> >>>>> Signed-off-by: David Gibson >>>>> --- >>>>> target-ppc/translate_init.c | 17 +++++++++++++++++ >>>>> 1 file changed, 17 insertions(+) >>>>> >>>>> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c >>>>> index e88dc7f..ae5a269 100644 >>>>> --- a/target-ppc/translate_init.c >>>>> +++ b/target-ppc/translate_init.c >>>>> @@ -8200,6 +8200,22 @@ POWERPC_FAMILY(POWER8)(ObjectClass *oc, void *data) >>>>> { >>>>> DeviceClass *dc = DEVICE_CLASS(oc); >>>>> PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc); >>>>> + static const struct ppc_segment_page_sizes POWER8_sps = { >>>>> + .sps = { >>>>> + { .page_shift = 12, /* 4K */ >>>>> + .slb_enc = 0, >>>>> + .enc = { { .page_shift = 12, .pte_enc = 0 } } >>>>> + }, >>>>> + { .page_shift = 16, /* 64K */ >>>>> + .slb_enc = 0x110, >>>>> + .enc = { { .page_shift = 16, .pte_enc = 0x1 } } >>>>> + }, >>>>> + { .page_shift = 24, /* 16M */ >>>>> + .slb_enc = 0x100, >>>>> + .enc = { { .page_shift = 24, .pte_enc = 0 } } >>>>> + }, >>>>> + } >>>>> + }; >>>> >>>> >>>> In order to educate myself - where did 0x110/0x100 come from? >>> >>> These are the L and LP bit encodings used by actual POWER8 hardware - >>> IIRC I took the information from the kernel's mmu_psize_defs table. >> >> >> I found this in p8-book4. Paul suggested there is a public POWER8 user >> manual but I cannot neither google it nor find on >> http://openpowerfoundation.org/. > > Ok. Ah. Forgot the main point - this encoding is the same in P7_BookIV so this could be used for P7 as well. > >> >> >>>> Is not 0x110 >>>> SLB_VSID_64K (which does not use SLB_VSID_L by accident?)? >>> >>> Yes, it is >>> >>>> And is 0x100 >>>> SLB_VSID_L? >>> >>> Yes. >> >> Cool, thanks. >> >> btw why not to use those definitions then... > > I think I started trying to, but got into some #include complications > that weren't worth the hassling of sorting out at the time. A bit weird but ok. -- Alexey