From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752806AbbBRKnA (ORCPT ); Wed, 18 Feb 2015 05:43:00 -0500 Received: from cantor2.suse.de ([195.135.220.15]:50033 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751826AbbBRKm7 (ORCPT ); Wed, 18 Feb 2015 05:42:59 -0500 Message-ID: <54E46CB1.5010702@suse.com> Date: Wed, 18 Feb 2015 11:42:57 +0100 From: Juergen Gross User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Vrabel , linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, boris.ostrovsky@oracle.com Subject: Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure References: <1424242326-26611-1-git-send-email-jgross@suse.com> <1424242326-26611-3-git-send-email-jgross@suse.com> <54E46A33.9030401@citrix.com> In-Reply-To: <54E46A33.9030401@citrix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/18/2015 11:32 AM, David Vrabel wrote: > On 18/02/15 06:51, Juergen Gross wrote: >> The linear p2m list should be anchored in the shared info structure > > I'm not really sure what you mean by "anchored". Bad wording? What about: The virtual address of the linear p2m list should be stored in the shared info structure. > >> read by the Xen tools to be able to support 64 bit pv-domains larger >> than 512 MB. Additionally the linear p2m list interface includes a >> generation count which is changed prior to and after each mapping >> change of the p2m list. Reading the generation count the Xen tools can >> detect changes of the mappings and re-read the p2m list eventually. > [...] >> --- a/arch/x86/xen/p2m.c >> +++ b/arch/x86/xen/p2m.c >> @@ -256,6 +256,10 @@ void xen_setup_mfn_list_list(void) >> HYPERVISOR_shared_info->arch.pfn_to_mfn_frame_list_list = >> virt_to_mfn(p2m_top_mfn); >> HYPERVISOR_shared_info->arch.max_pfn = xen_max_p2m_pfn; >> + HYPERVISOR_shared_info->arch.p2m_generation = 0; >> + HYPERVISOR_shared_info->arch.p2m_vaddr = (unsigned long)xen_p2m_addr; >> + HYPERVISOR_shared_info->arch.p2m_cr3 = >> + xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir)); >> } >> >> /* Set up p2m_top to point to the domain-builder provided p2m pages */ >> @@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t *pte_pg) >> >> ptechk = lookup_address(vaddr, &level); >> if (ptechk == pte_pg) { >> + HYPERVISOR_shared_info->arch.p2m_generation++; >> set_pmd(pmdp, >> __pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE)); >> + HYPERVISOR_shared_info->arch.p2m_generation++; > > Do these increments of p2m_generation need to be atomic? Hmm, they are done under lock. I don't think the compiler is allowed to reorder the writes to p2m_generation across set_pmd(). Juergen