From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932885AbdCGSTq convert rfc822-to-8bit (ORCPT ); Tue, 7 Mar 2017 13:19:46 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:51029 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755536AbdCGSTY (ORCPT ); Tue, 7 Mar 2017 13:19:24 -0500 Subject: Re: [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and xen_cleanmfnmap() to support p4d To: "Kirill A. Shutemov" , "Zhang, Xiong Y" References: <20170306135357.3124-1-kirill.shutemov@linux.intel.com> <20170306135357.3124-19-kirill.shutemov@linux.intel.com> <20170307130009.GA2154@node> Cc: "Kirill A. Shutemov" , Linus Torvalds , Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , Arnd Bergmann , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Juergen Gross , xen-devel From: Boris Ostrovsky Message-ID: <8bd7d5b7-7a22-a0a2-8eff-e909a1c6783e@oracle.com> Date: Tue, 7 Mar 2017 13:18:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170307130009.GA2154@node> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> Don't we need to pass vaddr down to all routines so that they select >> appropriate tables? You seem to always be choosing the first one. > IIUC, we clear whole page table subtree covered by one pgd entry. > So, no, there's no need to pass vaddr down. Just pointer to page table > entry is enough. > > But I know virtually nothing about Xen. Please re-check my reasoning. Yes, we effectively remove the whole page table for vaddr so I guess it's OK. > > I would also appreciate help with getting x86 Xen code work with 5-level > paging enabled. For now I make CONFIG_XEN dependent on !CONFIG_X86_5LEVEL. Hmmm... that's a problem since this requires changes in the hypervisor and even if/when these changes are made older version of hypervisor still will not be able to run those guests. This affects only PV guests and there is a series under review that provides clean code separation with CONFIG_XEN_PV but because, for example, dom0 (Xen control domain) is PV this will significantly limit availability of dom0-capable kernels (because I assume distros will want to have CONFIG_X86_5LEVEL). > > Fixup: Yes, that works. (But then it worked even without this change because problems caused by missing the flush would be intermittent. And a joy to debug). -boris