Xen devel - Mar 2013 - [PATCH] xen/SandyBridge: reserve pages when integrated graphics

SNB graphics devices have a bug that prevent them from accessing certain
memory ranges, namely anything below 1M and in the pages listed in the
table.

Xen does not initialize below 1MB to heap, i.e. below 1MB pages don''t
be
allocated, so it''s unnecessary to reserve memory below the 1 MB mark
that has not already been reserved.

So reserve those pages listed in the table at xen boot if set detect a
SNB gfx device on the CPU to avoid GPU hangs.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/mm.c                    | 14 ++++++++++++
 xen/common/page_alloc.c              | 42 +++++++++++++++++++++++++-----------
 xen/drivers/passthrough/vtd/quirks.c |  2 +-
 xen/include/asm-x86/mm.h             |  1 +
 xen/include/asm-x86/pci.h            |  5 +++++
 5 files changed, 50 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index add93ac..5e706af 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -121,6 +121,7 @@
 #include <xen/trace.h>
 #include <asm/setup.h>
 #include <asm/fixmap.h>
+#include <asm/pci.h>
 
 /* Mapping of the fixmap space needed early. */
 l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
@@ -5597,6 +5598,19 @@ void arch_dump_shared_mem_info(void)
             mem_sharing_get_nr_saved_mfns());
 }
 
+char *__init get_platform_badpages(void)
+{
+    u32 igd_id;
+    static char __initdata bad_pfns[] = 
+                {"0x20050,0x20110,0x20130,0x20138,0x40004"};
+
+    igd_id = pci_conf_read32(0, 0, 2, 0, 0);
+    if (!IS_SNB_GFX(igd_id))
+        return NULL;
+
+    return bad_pfns;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9e9fb15..f818090 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -148,22 +148,10 @@ static void __init bootmem_region_zap(unsigned long s,
unsigned long e)
     }
 }
 
-void __init init_boot_pages(paddr_t ps, paddr_t pe)
+static void __init remove_bad_pages(const char *p)
 {
     unsigned long bad_spfn, bad_epfn;
-    const char *p;
-
-    ps = round_pgup(ps);
-    pe = round_pgdown(pe);
-    if ( pe <= ps )
-        return;
-
-    first_valid_mfn = min_t(unsigned long, ps >> PAGE_SHIFT,
first_valid_mfn);
-
-    bootmem_region_add(ps >> PAGE_SHIFT, pe >> PAGE_SHIFT);
-
     /* Check new pages against the bad-page list. */
-    p = opt_badpage;
     while ( *p != ''\0'' )
     {
         bad_spfn = simple_strtoul(p, &p, 0);
@@ -186,6 +174,34 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
     }
 }
 
+void __init init_boot_pages(paddr_t ps, paddr_t pe)
+{
+    const char *p;
+
+    ps = round_pgup(ps);
+    pe = round_pgdown(pe);
+    if ( pe <= ps )
+        return;
+
+    first_valid_mfn = min_t(unsigned long, ps >> PAGE_SHIFT,
first_valid_mfn);
+
+    bootmem_region_add(ps >> PAGE_SHIFT, pe >> PAGE_SHIFT);
+
+#ifdef CONFIG_X86
+    /* 
+     * Here we put platform-specific memory range workarounds, i.e.
+     * memory known to be corrupt or otherwise in need to be reserved on
+     * specific platforms.
+     * We get these certain pages and put them in bad-page list.
+     */
+    p = get_platform_badpages();
+    if ( p )
+        remove_bad_pages(p);
+#endif
+    p = opt_badpage;
+    remove_bad_pages(p);
+}
+
 unsigned long __init alloc_boot_pages(
     unsigned long nr_pfns, unsigned long pfn_align)
 {
diff --git a/xen/drivers/passthrough/vtd/quirks.c
b/xen/drivers/passthrough/vtd/quirks.c
index d79a155..70d57de 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -31,6 +31,7 @@
 #include <xen/keyhandler.h>
 #include <asm/msi.h>
 #include <asm/irq.h>
+#include <asm/pci.h>
 #include <mach_apic.h>
 #include "iommu.h"
 #include "dmar.h"
@@ -47,7 +48,6 @@
 #define IS_CTG(id)    (id == 0x2a408086)
 #define IS_ILK(id)    (id == 0x00408086 || id == 0x00448086 || id== 0x00628086
|| id == 0x006A8086)
 #define IS_CPT(id)    (id == 0x01008086 || id == 0x01048086)
-#define IS_SNB_GFX(id) (id == 0x01068086 || id == 0x01168086 || id ==
0x01268086 || id == 0x01028086 || id == 0x01128086 || id == 0x01228086 || id ==
0x010A8086)
 
 static u32 __read_mostly ioh_id;
 static u32 __initdata igd_id;
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index 4f89dae..7af069f 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -322,6 +322,7 @@ int is_iomem_page(unsigned long mfn);
 
 void clear_superpage_mark(struct page_info *page);
 
+char *get_platform_badpages(void);
 /* Per page locks:
  * page_lock() is used for two purposes: pte serialization, and memory sharing.
  *
diff --git a/xen/include/asm-x86/pci.h b/xen/include/asm-x86/pci.h
index 7bcb702..e0598fd 100644
--- a/xen/include/asm-x86/pci.h
+++ b/xen/include/asm-x86/pci.h
@@ -1,6 +1,11 @@
 #ifndef __X86_PCI_H__
 #define __X86_PCI_H__
 
+#define IS_SNB_GFX(id) (id == 0x01068086 || id == 0x01168086 \
+                        || id == 0x01268086 || id == 0x01028086 \
+                        || id == 0x01128086 || id == 0x01228086 \
+                        || id == 0x010A8086 )
+
 struct arch_pci_dev {
     vmask_t used_vectors;
 };
-- 
1.7.12.1

>>> On 22.03.13 at 08:48, Xudong Hao <xudong.hao@intel.com>
wrote:
> +char *__init get_platform_badpages(void)
> +{
> +    u32 igd_id;
> +    static char __initdata bad_pfns[] = 
> +                {"0x20050,0x20110,0x20130,0x20138,0x40004"};
With quite a bit of trouble I managed to find all applicable spec
updates, but none of them mentions 0x20110.
> +#ifdef CONFIG_X86
> +    /* 
> +     * Here we put platform-specific memory range workarounds, i.e.
> +     * memory known to be corrupt or otherwise in need to be reserved on
> +     * specific platforms.
> +     * We get these certain pages and put them in bad-page list.
> +     */
> +    p = get_platform_badpages();
> +    if ( p )
> +        remove_bad_pages(p);
> +#endif
I also dislike the re-use of the command line parsing code here.
There''s no need to do this for a list of known MFNs, the hook
could provide an array of unsigned long instead.

And finally it is my understanding that these pages aren''t bad in
any way, it must only be ensured they don''t get passed to the
graphics engine. Which in particular means using these pages for
Xen''s own purposes (i.e. not passing them to any domain) would
be quite fine. Yes, I realize it''s only a handful of pages, but it
seems odd anyway.

Jan

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, March 22, 2013 6:27 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; keir@xen.org
> Subject: Re: [PATCH] xen/SandyBridge: reserve pages when integrated
graphics
> 
> >>> On 22.03.13 at 08:48, Xudong Hao <xudong.hao@intel.com>
wrote:
> > +char *__init get_platform_badpages(void)
> > +{
> > +    u32 igd_id;
> > +    static char __initdata bad_pfns[] > > +               
{"0x20050,0x20110,0x20130,0x20138,0x40004"};
> 
> With quite a bit of trouble I managed to find all applicable spec
> updates, but none of them mentions 0x20110.
> 
I did not get detail spec either, but linux kernel has remove this page
0x20110000 already for the same reason, refer to commit:
a9acc5365dbda29f7be2884efb63771dc24bd815
> > +#ifdef CONFIG_X86
> > +    /*
> > +     * Here we put platform-specific memory range workarounds, i.e.
> > +     * memory known to be corrupt or otherwise in need to be reserved
on
> > +     * specific platforms.
> > +     * We get these certain pages and put them in bad-page list.
> > +     */
> > +    p = get_platform_badpages();
> > +    if ( p )
> > +        remove_bad_pages(p);
> > +#endif
> 
> I also dislike the re-use of the command line parsing code here.
> There''s no need to do this for a list of known MFNs, the hook
> could provide an array of unsigned long instead.
> 
Right. bootmem_region_zap() can do this directly.
> And finally it is my understanding that these pages aren''t bad in
> any way, it must only be ensured they don''t get passed to the
> graphics engine. Which in particular means using these pages for
> Xen''s own purposes (i.e. not passing them to any domain) would
> be quite fine. Yes, I realize it''s only a handful of pages, but it
> seems odd anyway.
> 
We all know these pages can be used for Xen, but not for domains. But as you
said, it''s only 5 pages, the simplest solution is removing them in xen
starting, so that they don''t be allocate to any domains.

-Thanks
Xudong

>>> On 23.03.13 at 15:51, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, March 22, 2013 6:27 PM
>> To: Hao, Xudong
>> Cc: xen-devel@lists.xen.org; keir@xen.org 
>> Subject: Re: [PATCH] xen/SandyBridge: reserve pages when integrated
graphics
>> 
>> >>> On 22.03.13 at 08:48, Xudong Hao
<xudong.hao@intel.com> wrote:
>> > +char *__init get_platform_badpages(void)
>> > +{
>> > +    u32 igd_id;
>> > +    static char __initdata bad_pfns[] >> > +            
{"0x20050,0x20110,0x20130,0x20138,0x40004"};
>> 
>> With quite a bit of trouble I managed to find all applicable spec
>> updates, but none of them mentions 0x20110.
>> 
> I did not get detail spec either, but linux kernel has remove this page 
> 0x20110000 already for the same reason, refer to commit: 
> a9acc5365dbda29f7be2884efb63771dc24bd815
> 
>> > +#ifdef CONFIG_X86
>> > +    /*
>> > +     * Here we put platform-specific memory range workarounds,
i.e.
>> > +     * memory known to be corrupt or otherwise in need to be
reserved on
>> > +     * specific platforms.
>> > +     * We get these certain pages and put them in bad-page list.
>> > +     */
>> > +    p = get_platform_badpages();
>> > +    if ( p )
>> > +        remove_bad_pages(p);
>> > +#endif
>> 
>> I also dislike the re-use of the command line parsing code here.
>> There''s no need to do this for a list of known MFNs, the hook
>> could provide an array of unsigned long instead.
>> 
> Right. bootmem_region_zap() can do this directly.
So I supposed we''re going to see a v2 then, with both points
addressed?

Jan

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, March 25, 2013 5:28 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; keir@xen.org
> Subject: RE: [PATCH] xen/SandyBridge: reserve pages when integrated
graphics
> 
> >>> On 23.03.13 at 15:51, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Friday, March 22, 2013 6:27 PM
> >> To: Hao, Xudong
> >> Cc: xen-devel@lists.xen.org; keir@xen.org
> >> Subject: Re: [PATCH] xen/SandyBridge: reserve pages when
integrated
> graphics
> >>
> >> >>> On 22.03.13 at 08:48, Xudong Hao
<xudong.hao@intel.com> wrote:
> >> > +char *__init get_platform_badpages(void)
> >> > +{
> >> > +    u32 igd_id;
> >> > +    static char __initdata bad_pfns[] > >> > +  
{"0x20050,0x20110,0x20130,0x20138,0x40004"};
> >>
> >> With quite a bit of trouble I managed to find all applicable spec
> >> updates, but none of them mentions 0x20110.
> >>
> > I did not get detail spec either, but linux kernel has remove this
page
> > 0x20110000 already for the same reason, refer to commit:
> > a9acc5365dbda29f7be2884efb63771dc24bd815
> >
> >> > +#ifdef CONFIG_X86
> >> > +    /*
> >> > +     * Here we put platform-specific memory range
workarounds, i.e.
> >> > +     * memory known to be corrupt or otherwise in need to be
reserved
> on
> >> > +     * specific platforms.
> >> > +     * We get these certain pages and put them in bad-page
list.
> >> > +     */
> >> > +    p = get_platform_badpages();
> >> > +    if ( p )
> >> > +        remove_bad_pages(p);
> >> > +#endif
> >>
> >> I also dislike the re-use of the command line parsing code here.
> >> There''s no need to do this for a list of known MFNs, the
hook
> >> could provide an array of unsigned long instead.
> >>
> > Right. bootmem_region_zap() can do this directly.
> 
> So I supposed we''re going to see a v2 then, with both points
> addressed?
> 
Surely, but v2 will modify only one point. I don''t know what''s
the 2nd point you mean?

>>> On 25.03.13 at 10:45, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Monday, March 25, 2013 5:28 PM
>> To: Hao, Xudong
>> Cc: xen-devel@lists.xen.org; keir@xen.org 
>> Subject: RE: [PATCH] xen/SandyBridge: reserve pages when integrated
graphics
>> 
>> >>> On 23.03.13 at 15:51, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
>> >>  -----Original Message-----
>> >> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> Sent: Friday, March 22, 2013 6:27 PM
>> >> To: Hao, Xudong
>> >> Cc: xen-devel@lists.xen.org; keir@xen.org 
>> >> Subject: Re: [PATCH] xen/SandyBridge: reserve pages when
integrated
>> graphics
>> >>
>> >> >>> On 22.03.13 at 08:48, Xudong Hao
<xudong.hao@intel.com> wrote:
>> >> > +char *__init get_platform_badpages(void)
>> >> > +{
>> >> > +    u32 igd_id;
>> >> > +    static char __initdata bad_pfns[] >> >>
> +                {"0x20050,0x20110,0x20130,0x20138,0x40004"};
>> >>
>> >> With quite a bit of trouble I managed to find all applicable
spec
>> >> updates, but none of them mentions 0x20110.
>> >>
>> > I did not get detail spec either, but linux kernel has remove this
page
>> > 0x20110000 already for the same reason, refer to commit:
>> > a9acc5365dbda29f7be2884efb63771dc24bd815
>> >
>> >> > +#ifdef CONFIG_X86
>> >> > +    /*
>> >> > +     * Here we put platform-specific memory range
workarounds, i.e.
>> >> > +     * memory known to be corrupt or otherwise in need
to be reserved
>> on
>> >> > +     * specific platforms.
>> >> > +     * We get these certain pages and put them in
bad-page list.
>> >> > +     */
>> >> > +    p = get_platform_badpages();
>> >> > +    if ( p )
>> >> > +        remove_bad_pages(p);
>> >> > +#endif
>> >>
>> >> I also dislike the re-use of the command line parsing code
here.
>> >> There''s no need to do this for a list of known MFNs,
the hook
>> >> could provide an array of unsigned long instead.
>> >>
>> > Right. bootmem_region_zap() can do this directly.
>> 
>> So I supposed we''re going to see a v2 then, with both points
>> addressed?
>> 
> Surely, but v2 will modify only one point. I don''t know
what''s the 2nd point
> you mean?
- removal of page 0x20110
- using MFNs directly rather than passing a string to parse

Jan

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, March 25, 2013 5:54 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; keir@xen.org
> Subject: RE: [PATCH] xen/SandyBridge: reserve pages when integrated
graphics
> 
> >>> On 25.03.13 at 10:45, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Monday, March 25, 2013 5:28 PM
> >> To: Hao, Xudong
> >> Cc: xen-devel@lists.xen.org; keir@xen.org
> >> Subject: RE: [PATCH] xen/SandyBridge: reserve pages when
integrated
> graphics
> >>
> >> >>> On 23.03.13 at 15:51, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
> >> >>  -----Original Message-----
> >> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >> Sent: Friday, March 22, 2013 6:27 PM
> >> >> To: Hao, Xudong
> >> >> Cc: xen-devel@lists.xen.org; keir@xen.org
> >> >> Subject: Re: [PATCH] xen/SandyBridge: reserve pages when
integrated
> >> graphics
> >> >>
> >> >> >>> On 22.03.13 at 08:48, Xudong Hao
<xudong.hao@intel.com> wrote:
> >> >> > +char *__init get_platform_badpages(void)
> >> >> > +{
> >> >> > +    u32 igd_id;
> >> >> > +    static char __initdata bad_pfns[] > >>
>> > +               
{"0x20050,0x20110,0x20130,0x20138,0x40004"};
> >> >>
> >> >> With quite a bit of trouble I managed to find all
applicable spec
> >> >> updates, but none of them mentions 0x20110.
> >> >>
> >> > I did not get detail spec either, but linux kernel has remove
this page
> >> > 0x20110000 already for the same reason, refer to commit:
> >> > a9acc5365dbda29f7be2884efb63771dc24bd815
> >> >
> >> >> > +#ifdef CONFIG_X86
> >> >> > +    /*
> >> >> > +     * Here we put platform-specific memory range
workarounds,
> i.e.
> >> >> > +     * memory known to be corrupt or otherwise in
need to be
> reserved
> >> on
> >> >> > +     * specific platforms.
> >> >> > +     * We get these certain pages and put them in
bad-page list.
> >> >> > +     */
> >> >> > +    p = get_platform_badpages();
> >> >> > +    if ( p )
> >> >> > +        remove_bad_pages(p);
> >> >> > +#endif
> >> >>
> >> >> I also dislike the re-use of the command line parsing
code here.
> >> >> There''s no need to do this for a list of known
MFNs, the hook
> >> >> could provide an array of unsigned long instead.
> >> >>
> >> > Right. bootmem_region_zap() can do this directly.
> >>
> >> So I supposed we''re going to see a v2 then, with both
points
> >> addressed?
> >>
> > Surely, but v2 will modify only one point. I don''t know
what''s the 2nd point
> > you mean?
> 
> - removal of page 0x20110
Linux kernel has put page 0x20110000 as bad, so we do not need to remove it from
bad page list.
Linux commit: a9acc5365dbda29f7be2884efb63771dc24bd815

>>> On 25.03.13 at 13:39, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> - removal of page 0x20110
> 
> Linux kernel has put page 0x20110000 as bad, so we do not need to remove it
> from bad page list.
> Linux commit: a9acc5365dbda29f7be2884efb63771dc24bd815
So then your earlier response was misleading, or at least confusing
me:

"I did not get detail spec either, but linux kernel has remove this page
 0x20110000 already for the same reason, refer to commit:
 a9acc5365dbda29f7be2884efb63771dc24bd815".

"Removed" to me meant removed from the list of bad PFNs. Note
that I didn''t look at the commit, I just took your response as
confirming that this particular PFN got added to the list in error.
Now that you say that you actually meant the exact opposite,
we''re back at the question why that PFN is in the list in the first
place, considering that none of the spec updates say so.

Jan

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, March 25, 2013 9:07 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; keir@xen.org
> Subject: RE: [PATCH] xen/SandyBridge: reserve pages when integrated
graphics
> 
> >>> On 25.03.13 at 13:39, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> - removal of page 0x20110
> >
> > Linux kernel has put page 0x20110000 as bad, so we do not need to
remove it
> > from bad page list.
> > Linux commit: a9acc5365dbda29f7be2884efb63771dc24bd815
> 
> So then your earlier response was misleading, or at least confusing
> me:
> 
> "I did not get detail spec either, but linux kernel has remove this
page
>  0x20110000 already for the same reason, refer to commit:
>  a9acc5365dbda29f7be2884efb63771dc24bd815".
> 
> "Removed" to me meant removed from the list of bad PFNs. Note
> that I didn''t look at the commit, I just took your response as
> confirming that this particular PFN got added to the list in error.
Sorry to confuse you, the earlier response really a little misleading. Actually
I want to say this page is inaccessible for SandyBridge graphic device.
> Now that you say that you actually meant the exact opposite,
> we''re back at the question why that PFN is in the list in the
first
> place, considering that none of the spec updates say so.
> 
Let me try to find out the description on spec.

Include page 0x20110000, the five pages are in spec and I have confirmed.
 
> -----Original Message-----
> From: Hao, Xudong
> Sent: Monday, March 25, 2013 9:37 PM
> To: Jan Beulich
> Cc: xen-devel@lists.xen.org; keir@xen.org
> Subject: RE: [PATCH] xen/SandyBridge: reserve pages when integrated
graphics
> 
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Monday, March 25, 2013 9:07 PM
> > To: Hao, Xudong
> > Cc: xen-devel@lists.xen.org; keir@xen.org
> > Subject: RE: [PATCH] xen/SandyBridge: reserve pages when integrated
> graphics
> >
> > >>> On 25.03.13 at 13:39, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
> > >> From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> - removal of page 0x20110
> > >
> > > Linux kernel has put page 0x20110000 as bad, so we do not need to
remove
> it
> > > from bad page list.
> > > Linux commit: a9acc5365dbda29f7be2884efb63771dc24bd815
> >
> > So then your earlier response was misleading, or at least confusing
> > me:
> >
> > "I did not get detail spec either, but linux kernel has remove
this page
> >  0x20110000 already for the same reason, refer to commit:
> >  a9acc5365dbda29f7be2884efb63771dc24bd815".
> >
> > "Removed" to me meant removed from the list of bad PFNs.
Note
> > that I didn''t look at the commit, I just took your response
as
> > confirming that this particular PFN got added to the list in error.
> 
> Sorry to confuse you, the earlier response really a little misleading.
Actually I
> want to say this page is inaccessible for SandyBridge graphic device.
> 
> > Now that you say that you actually meant the exact opposite,
> > we''re back at the question why that PFN is in the list in the
first
> > place, considering that none of the spec updates say so.
> >
> Let me try to find out the description on spec.

On Tue, Mar 26, 2013 at 09:00:48AM +0000, Hao, Xudong
wrote:
> Include page 0x20110000, the five pages are in spec and I have confirmed.
Could you also include the name of the spec and an URL (if there is one)
for it. That way in the future if there are some lingering questions
one can just reference the spec.
>  
> > -----Original Message-----
> > From: Hao, Xudong
> > Sent: Monday, March 25, 2013 9:37 PM
> > To: Jan Beulich
> > Cc: xen-devel@lists.xen.org; keir@xen.org
> > Subject: RE: [PATCH] xen/SandyBridge: reserve pages when integrated
graphics
> > 
> > > -----Original Message-----
> > > From: Jan Beulich [mailto:JBeulich@suse.com]
> > > Sent: Monday, March 25, 2013 9:07 PM
> > > To: Hao, Xudong
> > > Cc: xen-devel@lists.xen.org; keir@xen.org
> > > Subject: RE: [PATCH] xen/SandyBridge: reserve pages when
integrated
> > graphics
> > >
> > > >>> On 25.03.13 at 13:39, "Hao, Xudong"
<xudong.hao@intel.com> wrote:
> > > >> From: Jan Beulich [mailto:JBeulich@suse.com]
> > > >> - removal of page 0x20110
> > > >
> > > > Linux kernel has put page 0x20110000 as bad, so we do not
need to remove
> > it
> > > > from bad page list.
> > > > Linux commit: a9acc5365dbda29f7be2884efb63771dc24bd815
> > >
> > > So then your earlier response was misleading, or at least
confusing
> > > me:
> > >
> > > "I did not get detail spec either, but linux kernel has
remove this page
> > >  0x20110000 already for the same reason, refer to commit:
> > >  a9acc5365dbda29f7be2884efb63771dc24bd815".
> > >
> > > "Removed" to me meant removed from the list of bad
PFNs. Note
> > > that I didn''t look at the commit, I just took your
response as
> > > confirming that this particular PFN got added to the list in
error.
> > 
> > Sorry to confuse you, the earlier response really a little misleading.
Actually I
> > want to say this page is inaccessible for SandyBridge graphic device.
> > 
> > > Now that you say that you actually meant the exact opposite,
> > > we''re back at the question why that PFN is in the list
in the first
> > > place, considering that none of the spec updates say so.
> > >
> > Let me try to find out the description on spec.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>