From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752847AbbBRK5r (ORCPT ); Wed, 18 Feb 2015 05:57:47 -0500 Received: from cantor2.suse.de ([195.135.220.15]:51199 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752717AbbBRK5q (ORCPT ); Wed, 18 Feb 2015 05:57:46 -0500 Message-ID: <54E47029.6010807@suse.com> Date: Wed, 18 Feb 2015 11:57:45 +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 , Andrew Cooper , 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> <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; 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:54 AM, 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(). Okay, will do. Juergen