diff mbox

GHES: correct page protection flags in ghes_ioremap_pfn_...()

Message ID 5049B2FF02000078000998F3@nat28.tlf.novell.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jan Beulich Sept. 7, 2012, 6:40 a.m. UTC
At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
translation otherwise done in PV guests. (The offending commit was
81e88fdc432a1552401d6e91a984dcccce72b8dc.)

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
 drivers/acpi/apei/ghes.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)




--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Huang, Ying Sept. 7, 2012, 7:02 a.m. UTC | #1
On Fri, 2012-09-07 at 07:40 +0100, Jan Beulich wrote:
> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
> translation otherwise done in PV guests. (The offending commit was
> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)

If my understanding were correct, ghes_ioremap_pfn_nmi normally only map
RAM.

Best Regards,
Huang Ying


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Beulich Sept. 7, 2012, 7:12 a.m. UTC | #2
>>> On 07.09.12 at 09:02, Huang Ying <ying.huang@intel.com> wrote:
> On Fri, 2012-09-07 at 07:40 +0100, Jan Beulich wrote:
>> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
>> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
>> translation otherwise done in PV guests. (The offending commit was
>> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)
> 
> If my understanding were correct, ghes_ioremap_pfn_nmi normally only map
> RAM.

But not RAM in the sense of what is seen as usable memory in the
E820 map. What you're mapping here is reserved memory, and that
is (from the perspective of the kernel and Xen) non-RAM. The fact
that it is RAM from a machine perspective is manifested by the
mapping not needing to be done UC or alike.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chen Gong Sept. 7, 2012, 7:18 a.m. UTC | #3
On Fri, Sep 07, 2012 at 07:40:31AM +0100, Jan Beulich wrote:
> Date:	Fri, 07 Sep 2012 07:40:31 +0100
> From: Jan Beulich <JBeulich@suse.com>
> To: Len Brown <lenb@kernel.org>
> Cc: ying.huang@intel.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
>  linux-acpi@vger.kernel.org
> Subject: [PATCH] GHES: correct page protection flags in
>  ghes_ioremap_pfn_...()
> X-Mailer: Novell GroupWise Internet Agent 12.0.0 
> 
> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
> translation otherwise done in PV guests. (The offending commit was
> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)
>

Oh, right. In virtual environment, physical address is virtualized, too.
We need to tell *ioremap* to map in proper address space. But I want
to do if you can update all related mappings for APEI tables? I'm not sure
if all APEI tables are affected by this issue.

> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: Huang Ying <ying.huang@intel.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> ---
>  drivers/acpi/apei/ghes.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- 3.6-rc4/drivers/acpi/apei/ghes.c
> +++ 3.6-rc4-ghes-ioremap-prot/drivers/acpi/apei/ghes.c
> @@ -206,7 +206,7 @@ static void __iomem *ghes_ioremap_pfn_nm
>  
>  	vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr);
>  	ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
> -			   pfn << PAGE_SHIFT, PAGE_KERNEL);
> +			   pfn << PAGE_SHIFT, PAGE_KERNEL_IO);
>  
>  	return (void __iomem *)vaddr;
>  }
> @@ -217,7 +217,7 @@ static void __iomem *ghes_ioremap_pfn_ir
>  
>  	vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
>  	ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
> -			   pfn << PAGE_SHIFT, PAGE_KERNEL);
> +			   pfn << PAGE_SHIFT, PAGE_KERNEL_IO);
>  
>  	return (void __iomem *)vaddr;
>  }
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Beulich Sept. 7, 2012, 8:12 a.m. UTC | #4
>>> On 07.09.12 at 09:18, Chen Gong <gong.chen@linux.intel.com> wrote:
> On Fri, Sep 07, 2012 at 07:40:31AM +0100, Jan Beulich wrote:
>> Date:	Fri, 07 Sep 2012 07:40:31 +0100
>> From: Jan Beulich <JBeulich@suse.com>
>> To: Len Brown <lenb@kernel.org>
>> Cc: ying.huang@intel.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
>>  linux-acpi@vger.kernel.org 
>> Subject: [PATCH] GHES: correct page protection flags in
>>  ghes_ioremap_pfn_...()
>> X-Mailer: Novell GroupWise Internet Agent 12.0.0 
>> 
>> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
>> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
>> translation otherwise done in PV guests. (The offending commit was
>> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)
>>
> 
> Oh, right. In virtual environment, physical address is virtualized, too.
> We need to tell *ioremap* to map in proper address space. But I want
> to do if you can update all related mappings for APEI tables? I'm not sure
> if all APEI tables are affected by this issue.

The other mappings that I found might be relevant use ioremap(),
i.e. don't specify protection flags on their own.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Huang, Ying Sept. 7, 2012, 8:46 a.m. UTC | #5
On Fri, 2012-09-07 at 08:12 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 09:02, Huang Ying <ying.huang@intel.com> wrote:
> > On Fri, 2012-09-07 at 07:40 +0100, Jan Beulich wrote:
> >> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
> >> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
> >> translation otherwise done in PV guests. (The offending commit was
> >> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)
> > 
> > If my understanding were correct, ghes_ioremap_pfn_nmi normally only map
> > RAM.
> 
> But not RAM in the sense of what is seen as usable memory in the
> E820 map. What you're mapping here is reserved memory, and that
> is (from the perspective of the kernel and Xen) non-RAM. The fact
> that it is RAM from a machine perspective is manifested by the
> mapping not needing to be done UC or alike.

I think the key is to keep these memory range map consistent between
each other.  BIOS may map these memory cached.  ACPI may mapped them as
cached (see acpi_os_ioremap) too.

Best Regards,
Huang Ying



--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Beulich Sept. 7, 2012, 8:51 a.m. UTC | #6
>>> On 07.09.12 at 10:46, Huang Ying <ying.huang@intel.com> wrote:
> On Fri, 2012-09-07 at 08:12 +0100, Jan Beulich wrote:
>> >>> On 07.09.12 at 09:02, Huang Ying <ying.huang@intel.com> wrote:
>> > On Fri, 2012-09-07 at 07:40 +0100, Jan Beulich wrote:
>> >> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
>> >> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
>> >> translation otherwise done in PV guests. (The offending commit was
>> >> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)
>> > 
>> > If my understanding were correct, ghes_ioremap_pfn_nmi normally only map
>> > RAM.
>> 
>> But not RAM in the sense of what is seen as usable memory in the
>> E820 map. What you're mapping here is reserved memory, and that
>> is (from the perspective of the kernel and Xen) non-RAM. The fact
>> that it is RAM from a machine perspective is manifested by the
>> mapping not needing to be done UC or alike.
> 
> I think the key is to keep these memory range map consistent between
> each other.  BIOS may map these memory cached.  ACPI may mapped them as
> cached (see acpi_os_ioremap) too.

But that aspect is orthogonal to the patch here - all we need
done for Xen is the proper setting of _PAGE_IO; cachability
is being dealt with independently (and correctly I think).

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Huang, Ying Sept. 7, 2012, 8:55 a.m. UTC | #7
On Fri, 2012-09-07 at 09:51 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 10:46, Huang Ying <ying.huang@intel.com> wrote:
> > On Fri, 2012-09-07 at 08:12 +0100, Jan Beulich wrote:
> >> >>> On 07.09.12 at 09:02, Huang Ying <ying.huang@intel.com> wrote:
> >> > On Fri, 2012-09-07 at 07:40 +0100, Jan Beulich wrote:
> >> >> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
> >> >> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
> >> >> translation otherwise done in PV guests. (The offending commit was
> >> >> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)
> >> > 
> >> > If my understanding were correct, ghes_ioremap_pfn_nmi normally only map
> >> > RAM.
> >> 
> >> But not RAM in the sense of what is seen as usable memory in the
> >> E820 map. What you're mapping here is reserved memory, and that
> >> is (from the perspective of the kernel and Xen) non-RAM. The fact
> >> that it is RAM from a machine perspective is manifested by the
> >> mapping not needing to be done UC or alike.
> > 
> > I think the key is to keep these memory range map consistent between
> > each other.  BIOS may map these memory cached.  ACPI may mapped them as
> > cached (see acpi_os_ioremap) too.
> 
> But that aspect is orthogonal to the patch here - all we need
> done for Xen is the proper setting of _PAGE_IO; cachability
> is being dealt with independently (and correctly I think).

Sorry, don't know much about Xen.  Just think we should keep mapping
consistent about whether cached in native environment.

Best Regards,
Huang Ying


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Beulich Sept. 7, 2012, 9:02 a.m. UTC | #8
>>> On 07.09.12 at 10:55, Huang Ying <ying.huang@intel.com> wrote:
> On Fri, 2012-09-07 at 09:51 +0100, Jan Beulich wrote:
>> >>> On 07.09.12 at 10:46, Huang Ying <ying.huang@intel.com> wrote:
>> > On Fri, 2012-09-07 at 08:12 +0100, Jan Beulich wrote:
>> >> >>> On 07.09.12 at 09:02, Huang Ying <ying.huang@intel.com> wrote:
>> >> > On Fri, 2012-09-07 at 07:40 +0100, Jan Beulich wrote:
>> >> >> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
>> >> >> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
>> >> >> translation otherwise done in PV guests. (The offending commit was
>> >> >> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)
>> >> > 
>> >> > If my understanding were correct, ghes_ioremap_pfn_nmi normally only map
>> >> > RAM.
>> >> 
>> >> But not RAM in the sense of what is seen as usable memory in the
>> >> E820 map. What you're mapping here is reserved memory, and that
>> >> is (from the perspective of the kernel and Xen) non-RAM. The fact
>> >> that it is RAM from a machine perspective is manifested by the
>> >> mapping not needing to be done UC or alike.
>> > 
>> > I think the key is to keep these memory range map consistent between
>> > each other.  BIOS may map these memory cached.  ACPI may mapped them as
>> > cached (see acpi_os_ioremap) too.
>> 
>> But that aspect is orthogonal to the patch here - all we need
>> done for Xen is the proper setting of _PAGE_IO; cachability
>> is being dealt with independently (and correctly I think).
> 
> Sorry, don't know much about Xen.  Just think we should keep mapping
> consistent about whether cached in native environment.

Of course. And nothing changes with the patch in that regard.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Huang, Ying Sept. 7, 2012, 2:39 p.m. UTC | #9
On Fri, 2012-09-07 at 10:02 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 10:55, Huang Ying <ying.huang@intel.com> wrote:
> > On Fri, 2012-09-07 at 09:51 +0100, Jan Beulich wrote:
> >> >>> On 07.09.12 at 10:46, Huang Ying <ying.huang@intel.com> wrote:
> >> > On Fri, 2012-09-07 at 08:12 +0100, Jan Beulich wrote:
> >> >> >>> On 07.09.12 at 09:02, Huang Ying <ying.huang@intel.com> wrote:
> >> >> > On Fri, 2012-09-07 at 07:40 +0100, Jan Beulich wrote:
> >> >> >> At least for Xen Dom0 it is very relevant to set the _PAGE_IO bit when
> >> >> >> ioremap-ing (non-RAM) areas, as that flag suppresses the PFN -> MFN
> >> >> >> translation otherwise done in PV guests. (The offending commit was
> >> >> >> 81e88fdc432a1552401d6e91a984dcccce72b8dc.)
> >> >> > 
> >> >> > If my understanding were correct, ghes_ioremap_pfn_nmi normally only map
> >> >> > RAM.
> >> >> 
> >> >> But not RAM in the sense of what is seen as usable memory in the
> >> >> E820 map. What you're mapping here is reserved memory, and that
> >> >> is (from the perspective of the kernel and Xen) non-RAM. The fact
> >> >> that it is RAM from a machine perspective is manifested by the
> >> >> mapping not needing to be done UC or alike.
> >> > 
> >> > I think the key is to keep these memory range map consistent between
> >> > each other.  BIOS may map these memory cached.  ACPI may mapped them as
> >> > cached (see acpi_os_ioremap) too.
> >> 
> >> But that aspect is orthogonal to the patch here - all we need
> >> done for Xen is the proper setting of _PAGE_IO; cachability
> >> is being dealt with independently (and correctly I think).
> > 
> > Sorry, don't know much about Xen.  Just think we should keep mapping
> > consistent about whether cached in native environment.
> 
> Of course. And nothing changes with the patch in that regard.

Yes.  So I have no objection to the patch.

Reviewed-by: Huang Ying <ying.huang@intel.com>

Best Regards,
Huang Ying



--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- 3.6-rc4/drivers/acpi/apei/ghes.c
+++ 3.6-rc4-ghes-ioremap-prot/drivers/acpi/apei/ghes.c
@@ -206,7 +206,7 @@  static void __iomem *ghes_ioremap_pfn_nm
 
 	vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr);
 	ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
-			   pfn << PAGE_SHIFT, PAGE_KERNEL);
+			   pfn << PAGE_SHIFT, PAGE_KERNEL_IO);
 
 	return (void __iomem *)vaddr;
 }
@@ -217,7 +217,7 @@  static void __iomem *ghes_ioremap_pfn_ir
 
 	vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
 	ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
-			   pfn << PAGE_SHIFT, PAGE_KERNEL);
+			   pfn << PAGE_SHIFT, PAGE_KERNEL_IO);
 
 	return (void __iomem *)vaddr;
 }