From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752641AbbBRK5e (ORCPT ); Wed, 18 Feb 2015 05:57:34 -0500 Received: from smtp.citrix.com ([66.165.176.89]:50329 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751315AbbBRK5d (ORCPT ); Wed, 18 Feb 2015 05:57:33 -0500 X-IronPort-AV: E=Sophos;i="5.09,512,1418083200"; d="scan'208";a="226733069" Message-ID: <54E4701A.9030300@citrix.com> Date: Wed, 18 Feb 2015 10:57:30 +0000 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: David Vrabel , Juergen Gross , , , , 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> <54E46CB1.5010702@suse.com> <54E46E61.8030805@citrix.com> <54E46F50.8080202@citrix.com> In-Reply-To: <54E46F50.8080202@citrix.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/02/15 10:54, David Vrabel wrote: > On 18/02/15 10:50, Andrew Cooper wrote: >> On 18/02/15 10:42, Juergen Gross wrote: >>>>> /* 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(). >> They do need smp_wmb() to guarantee that the increment is visible before >> the update occurs, just as the toolstack will need smp_rmb() to read. > smp_wmb() isn't good enough since you need the barrier even on non-smp > -- you need a wmb(). Ah yes. I was thinking in the wrong context for smp. In this case we need to guarantee interdomain consistency even with a UP guest kernel. ~Andrew