Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933264AbbLXIBk (ORCPT ); Thu, 24 Dec 2015 03:01:40 -0500 Received: from mga09.intel.com ([134.134.136.24]:29442 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751770AbbLXIBh (ORCPT ); Thu, 24 Dec 2015 03:01:37 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,472,1444719600"; d="scan'208";a="880253404" From: "Chen, Yu C" To: Andy Lutomirski , "Zheng, Lv" CC: "Moore, Robert" , "Wysocki, Rafael J" , "Brown, Len" , "Andy Lutomirski" , Lv Zheng , "linux-kernel@vger.kernel.org" , Linux ACPI , "H. Peter Anvin" , "Borislav Petkov" Subject: RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support Thread-Topic: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support Thread-Index: AQHRLXRnRL/kuZhBvUWr+aZgefsuPJ7KrTWAgABxKICAAKu9UIABCo7ggAIi7ACAB1SzoIAA6KaAgABNGQCAAXUZAIAA8C4w Date: Thu, 24 Dec 2015 08:01:24 +0000 Message-ID: <36DF59CE26D8EE47B0655C516E9CE64028688FD8@shsmsx102.ccr.corp.intel.com> References: <36DF59CE26D8EE47B0655C516E9CE64028686D35@shsmsx102.ccr.corp.intel.com> <1AE640813FDE7649BE1B193DEA596E883BB08C24@SHSMSX101.ccr.corp.intel.com> <36DF59CE26D8EE47B0655C516E9CE640286886D1@shsmsx102.ccr.corp.intel.com> <1AE640813FDE7649BE1B193DEA596E883BB0A29B@SHSMSX101.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGU5ZTAxNjgtZWQzMC00ZGM3LThlYzgtNDcwZWI2MzBlNzBlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNjVCZzFyUUw1OXdmbFN1TWVwQWtLajNXZDdibGwrWWNzcFJhSzNEMUZpaz0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tBO81jqq019988 Content-Length: 5155 Lines: 113 (resend for messy code) Hi, Andy > -----Original Message----- > From: Andy Lutomirski [mailto:luto@amacapital.net] > Sent: Thursday, December 24, 2015 9:40 AM > To: Zheng, Lv > Cc: Chen, Yu C; Moore, Robert; Wysocki, Rafael J; Brown, Len; Andy > Lutomirski; Lv Zheng; linux-kernel@vger.kernel.org; Linux ACPI; H. Peter > Anvin; Borislav Petkov > Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support > > On Tue, Dec 22, 2015 at 7:25 PM, Zheng, Lv wrote: > > Hi, Andy > > > >> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- > >> owner@vger.kernel.org] On Behalf Of Andy Lutomirski > >> Sent: Wednesday, December 23, 2015 6:49 AM > >> Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() > >> support > >> > >> On Mon, Dec 21, 2015 at 5:03 PM, Chen, Yu C > wrote: > >> > Hi Andy, > >> > thanks for your review, > >> > > >> >> -----Original Message----- > >> >> From: Andy Lutomirski [mailto:luto@amacapital.net] > >> >> Sent: Friday, December 18, 2015 1:00 AM > >> >> To: Zheng, Lv > >> >> Cc: Chen, Yu C; Moore, Robert; Wysocki, Rafael J; Brown, Len; Andy > >> >> Lutomirski; Lv Zheng; linux-kernel@vger.kernel.org; Linux ACPI; H. > >> >> Peter Anvin; Borislav Petkov > >> >> Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce > >> >> acpi_os_readable() > >> support > >> >> > >> > [cut] > >> >> > >> >> I think that hpa or Borislav [cc'd] could address the memory map > >> >> details better than I could. However, this functionality seems strange. > >> >> > >> >> Are these physical addresses or virtual addresses that are being > dumped? > >> > [Yu] They are virtual addresses to be dumped. > >> >> In either case, ISTM that using something iike page_is_ram might > >> >> be a lot simpler. > >> > [Yu] if i understand correctly, this API is used to check if the > >> > address is a valid 'kmalloc' style address, but not 'kmap' or > >> > 'vmalloc' address, and page_is_ram might treat the latter as valid > address? > >> > > >> > >> I'm a bit puzzled as to why this matters, but I have no fundamental > objection to doing it that way. > > [Lv Zheng] > > IMO, using page_is_ram() or something similar, the problem is what we > need to solve in the current approach still need to be solved: > > 1. How can we convert a virtual address into a "struct page"? > > There is no kernel API to convert any virtual address into struct page. > > Even there is such a kernel API to convert kmap/vmalloc addresses, we > still couldn't use it. > > Because if we want to validate kmap/vmaloc pages, we need 2 APIs > rather than 1 API while ACPICA only provides 1 API for this purpose. > > The 2 APIs should be get/put style to ping the page mappings as the > mappings other than the direct mappings will not be stationary in the kernel > address space. > > Fortunately we needn't take care of the mappings other than the direct > mappings (reasons are in the 2nd comment). > > So we still need to use the direct mapping APIs here. > > 2. How can we ensure the page is a direct mapping page? > > I think Yu should confirm if there is such a common kernel API. > > If there is such an API, we should use it so that we can remove the arch > specific stuffs. > > > >> What's the use case, though? > > [Lv Zheng] > > Fortunately, currently ACPICA only uses this API to validate if a namespace > node, an operand object or a parser object is readable. > > See drivers/acpi/acpica/dbdisplay.c and drivers/acpi/acpica/dbcmds.c. > > > >> That is, what goes wrong if the function just always returns false? > > [Lv Zheng] > > 1. If it always returns false, then many ACPICA debugger internal object > conversion/dump functionalities won't be functioning. > > For example, you can try to type “dump \_SB" in acpidbg shell and it will > return an error: > > "Invalid named object at address xxxxxxxxxxxxxxxx" > > 2. While if this function always returns true (current linux-pm/linux-next > merged stuffs), we can see such a result: > > Object (ffffxxxxxxxxxxxx) Pathname: \_SB > > Name : _SB_ > > Type : 06 [Device] > > > > It seems a bit unfortunate to me that the ACPICA debugger lets userspace > choose what address to dump rather than dumping by pathname, but given > that constraint, I guess this function is needed. > > Can you do something like checking virt_addr_valid and then using > virt_to_pfn and page_is_ram? If that's not enough (e.g. if it doesn't work for > vmalloc addresses and you need those), you could try to do something like > slow_virt_to_phys, but you'd need to do some extra checks to avoid the > BUG in the function. > [Yu] This is a good method, firstly virt_addr_valid can exclude the vaddr of vmalloc/kmap , then slow_virt_to_phys can check if this vaddr has a valid pte physical address, but I guess we need another non-BUG_on version of slow_virt_to_phys, I'll try to test with your suggestion, thanks! Yu ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?