Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755142AbbLXBkx (ORCPT ); Wed, 23 Dec 2015 20:40:53 -0500 Received: from mail-ob0-f181.google.com ([209.85.214.181]:35364 "EHLO mail-ob0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752946AbbLXBkv convert rfc822-to-8bit (ORCPT ); Wed, 23 Dec 2015 20:40:51 -0500 MIME-Version: 1.0 In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB0A29B@SHSMSX101.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> From: Andy Lutomirski Date: Wed, 23 Dec 2015 17:40:30 -0800 Message-ID: Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4324 Lines: 82 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. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/