Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1297717

Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support

Show key headers only | View raw

On Tue, Dec 22, 2015 at 7:25 PM, Zheng, Lv <lv.zheng@intel.com> 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 <yu.c.chen@intel.com> 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/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support Andy Lutomirski <luto@amacapital.net> - 2015-12-15 00:30 +0100
  RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support "Chen, Yu C" <yu.c.chen@intel.com> - 2015-12-15 07:20 +0100
    RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support "Zheng, Lv" <lv.zheng@intel.com> - 2015-12-15 10:00 +0100
    RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support "Zheng, Lv" <lv.zheng@intel.com> - 2015-12-16 01:30 +0100
      Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support Andy Lutomirski <luto@amacapital.net> - 2015-12-17 18:00 +0100
        RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support "Chen, Yu C" <yu.c.chen@intel.com> - 2015-12-22 02:10 +0100
          Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support Andy Lutomirski <luto@amacapital.net> - 2015-12-22 23:50 +0100
            RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support "Zheng, Lv" <lv.zheng@intel.com> - 2015-12-23 04:30 +0100
              Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support Andy Lutomirski <luto@amacapital.net> - 2015-12-24 02:50 +0100
                RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support "Chen, Yu C" <yu.c.chen@intel.com> - 2015-12-24 09:00 +0100
                RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support "Chen, Yu C" <yu.c.chen@intel.com> - 2015-12-24 09:10 +0100

csiph-web