[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] xen: rename wrong named pfn related variables

  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 16 Aug 2021 14:57:53 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K9vFlkNw0IMkPaHSuMlVQuZNTssPIbuL561oH5v+rFg=; b=WEcP6H+t0otIs5XDNeXurSwIAC/p7j979o1PkA+iPvPn4Av+wkTjcq1BhC38MqaAiqlfAR701dGcn5MnBwwux4XSGI4ZCPJK/S+Y5I61NuDQ2oV3QNU7LdgUYnL0Ny+WeNF5ED05MvEaD2Dk+pk7HkiFEL11KiKRA30tpqxvs7vAF6KNvgBL5chdf4xaPe3XjOmxlDEpWzq1PH3CYUxDr/hTGQdb+QX/tkHSXIdmm9GocXVWUxXuLksNTuZOLMlX5arWvC3iopBAPNFZjPWMrCVjDXK0UpnMTDttyW8Ivt3NKLosf0noAnLYk6xX0ZEDQBoUN5VqO6hFYjM4/tXXXw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lhvTNbNqPR8ZUfcgHUPrx8kz/VwqU+6ms4Lnm6pkLt9DUB7+9ByMRawd0pHFWOSZIOWI8sIZn78piRevkp2+OF1E1HdngcH8V9y/w2w1yFoqQJuicJZDoqZJcWkMuCELxWI+quEaoJ2OiaDMIwW/yjqXyg6Kh0QHzfidA4k8oKhsnUunc+kCU0RWRcCfBa3b4ifC/N2His1sQMVg/+bhEWjITEN6Ty82DoF0sajh6SCiJm64POhbyHsG4j1Fn415ZOcj2dekb5Z3rIHH6Js5+j2HN7/MFFLvm4sTtbYXCPm/kCURxq+kBxBwWHaonRNPuekKOm2taGyAwSFqhEYSWA==
  • Authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=suse.com;
  • Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx
  • Delivery-date: Mon, 16 Aug 2021 12:58:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.08.2021 07:25, Juergen Gross wrote:
> On 03.08.21 12:42, Jan Beulich wrote:
>> On 30.07.2021 11:00, Juergen Gross wrote:
>>> On 16.06.21 12:43, Juergen Gross wrote:
>>>> On 16.06.21 11:56, Jan Beulich wrote:
>>>>> On 16.06.2021 09:30, Juergen Gross wrote:
>>>>>> --- a/arch/x86/xen/p2m.c
>>>>>> +++ b/arch/x86/xen/p2m.c
>>>>>> @@ -95,8 +95,8 @@ unsigned long *xen_p2m_addr __read_mostly;
>>>>>>    EXPORT_SYMBOL_GPL(xen_p2m_addr);
>>>>>>    unsigned long xen_p2m_size __read_mostly;
>>>>>>    EXPORT_SYMBOL_GPL(xen_p2m_size);
>>>>>> -unsigned long xen_max_p2m_pfn __read_mostly;
>>>>>> -EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
>>>>>> +unsigned long xen_p2m_max_size __read_mostly;
>>>>>> +EXPORT_SYMBOL_GPL(xen_p2m_max_size);
>>>>> Instead of renaming the exported variable (which will break consumers
>>>>> anyway), how about dropping the apparently unneeded export at this
>>>>> occasion?
>>>> Why do you think it isn't needed? It is being referenced via the inline
>>>> function __pfn_to_mfn() in arch/x86/include/asm/xen/page.h. And
>>>> __pfn_to_mfn() is used via lots of other inline functions and macros.
>>>>> Further it looks to me as if xen_p2m_size and this variable
>>>>> were actually always kept in sync, so I'd like to put up the question
>>>>> of dropping one of the two.
>>>> Hmm, should be possible, yes.
>>> Looking into this it seems this is not possible.
>>> xen_p2m_size always holds the number of p2m entries in the p2m table,
>>> including invalid ones at the end. xen_p2m_pfn_limit however contains
>>> the (rounded up) index after the last valid p2m entry.
>> I'm afraid I can't follow:
>> xen_build_dynamic_phys_to_machine() sets xen_p2m_size and then syncs
>> its value to what so far has been xen_max_p2m_pfn.
>> xen_vmalloc_p2m_tree() sets xen_max_p2m_pfn and then syncs its value
>> to xen_p2m_size.
>> I therefore can't see how the two values would hold different values,
>> except for the brief periods between updating one and then the other.
> The brief period in xen_vmalloc_p2m_tree() is the problematic one. The
> different values are especially important for the calls of
> __pfn_to_mfn() during xen_rebuild_p2m_list().

I'm still in trouble: Such __pfn_to_mfn() invocations would, afaics,
occur only in the context of page directory entry manipulation. Isn't
it the case that all valid RAM is below xen_p2m_size, and hence no
use of

        else if (unlikely(pfn < xen_max_p2m_pfn))
                return get_phys_to_machine(pfn);

would occur during that time window? (We're still way ahead of SMP
init, so what other CPUs might do does not look to be of concern




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.