Message-ID: <36DF59CE26D8EE47B0655C516E9CE64028688FD8@shsmsx102.ccr.corp.intel.com>
Date:	Thu, 24 Dec 2015 08:01:24 +0000
From:	"Chen, Yu C" <yu.c.chen@...el.com>
To:	Andy Lutomirski <luto@...capital.net>,
	"Zheng, Lv" <lv.zheng@...el.com>
CC:	"Moore, Robert" <robert.moore@...el.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Brown, Len" <len.brown@...el.com>,
	"Andy Lutomirski" <luto@...nel.org>, Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, "Borislav Petkov" <bp@...en8.de>
Subject: RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support

(resend for messy code)
Hi, Andy

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@...capital.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@...r.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 <lv.zheng@...el.com> wrote:
> > Hi, Andy
> >
> >> From: linux-acpi-owner@...r.kernel.org [mailto:linux-acpi-
> >> owner@...r.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@...el.com>
> wrote:
> >> > Hi Andy,
> >> > thanks for your review,
> >> >
> >> >> -----Original Message-----
> >> >> From: Andy Lutomirski [mailto:luto@...capital.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@...r.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

Powered by blists - more mailing lists