From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752449AbbBRKuN (ORCPT <rfc822;w@1wt.eu>);
	Wed, 18 Feb 2015 05:50:13 -0500
Received: from smtp.citrix.com ([66.165.176.89]:1219 "EHLO SMTP.CITRIX.COM"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751628AbbBRKuM convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 18 Feb 2015 05:50:12 -0500
X-IronPort-AV: E=Sophos;i="5.09,600,1418083200"; 
   d="scan'208";a="226731715"
Message-ID: <54E46E61.8030805@citrix.com>
Date: Wed, 18 Feb 2015 10:50:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0
MIME-Version: 1.0
To: Juergen Gross <jgross@suse.com>, David Vrabel <david.vrabel@citrix.com>,
        <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>
In-Reply-To: <54E46CB1.5010702@suse.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8BIT
X-DLP: MIA2
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

They also need to be protected from concurrent update inside the kernel,
for which a lock should appear to suffice.

~Andrew