All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xen/SandyBridge: reserve pages when integrated graphics
@ 2013-03-22  7:48 Xudong Hao
  2013-03-22 10:26 ` Jan Beulich
  0 siblings, 1 reply; 11+ messages in thread
From: Xudong Hao @ 2013-03-22  7:48 UTC (permalink / raw)
  To: xen-devel; +Cc: Xudong Hao, keir, JBeulich

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

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-22  7:48 [PATCH] xen/SandyBridge: reserve pages when integrated graphics Xudong Hao
@ 2013-03-22 10:26 ` Jan Beulich
  2013-03-23 14:51   ` Hao, Xudong
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2013-03-22 10:26 UTC (permalink / raw)
  To: Xudong Hao; +Cc: keir, xen-devel

>>> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-22 10:26 ` Jan Beulich
@ 2013-03-23 14:51   ` Hao, Xudong
  2013-03-25  9:28     ` Jan Beulich
  0 siblings, 1 reply; 11+ messages in thread
From: Hao, Xudong @ 2013-03-23 14:51 UTC (permalink / raw)
  To: Jan Beulich; +Cc: keir, xen-devel

> -----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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-23 14:51   ` Hao, Xudong
@ 2013-03-25  9:28     ` Jan Beulich
  2013-03-25  9:45       ` Hao, Xudong
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2013-03-25  9:28 UTC (permalink / raw)
  To: Xudong Hao; +Cc: keir, xen-devel

>>> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-25  9:28     ` Jan Beulich
@ 2013-03-25  9:45       ` Hao, Xudong
  2013-03-25  9:54         ` Jan Beulich
  0 siblings, 1 reply; 11+ messages in thread
From: Hao, Xudong @ 2013-03-25  9:45 UTC (permalink / raw)
  To: Jan Beulich; +Cc: keir, xen-devel

> -----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?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-25  9:45       ` Hao, Xudong
@ 2013-03-25  9:54         ` Jan Beulich
  2013-03-25 12:39           ` Hao, Xudong
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2013-03-25  9:54 UTC (permalink / raw)
  To: Xudong Hao; +Cc: keir, xen-devel

>>> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-25  9:54         ` Jan Beulich
@ 2013-03-25 12:39           ` Hao, Xudong
  2013-03-25 13:06             ` Jan Beulich
  0 siblings, 1 reply; 11+ messages in thread
From: Hao, Xudong @ 2013-03-25 12:39 UTC (permalink / raw)
  To: Jan Beulich; +Cc: keir, xen-devel

> -----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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-25 12:39           ` Hao, Xudong
@ 2013-03-25 13:06             ` Jan Beulich
  2013-03-25 13:37               ` Hao, Xudong
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2013-03-25 13:06 UTC (permalink / raw)
  To: Xudong Hao; +Cc: keir, xen-devel

>>> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-25 13:06             ` Jan Beulich
@ 2013-03-25 13:37               ` Hao, Xudong
  2013-03-26  9:00                 ` Hao, Xudong
  0 siblings, 1 reply; 11+ messages in thread
From: Hao, Xudong @ 2013-03-25 13:37 UTC (permalink / raw)
  To: Jan Beulich; +Cc: keir, xen-devel

> -----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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-25 13:37               ` Hao, Xudong
@ 2013-03-26  9:00                 ` Hao, Xudong
  2013-03-26 13:15                   ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 11+ messages in thread
From: Hao, Xudong @ 2013-03-26  9:00 UTC (permalink / raw)
  To: 'Jan Beulich'
  Cc: 'keir@xen.org', 'xen-devel@lists.xen.org'

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
  2013-03-26  9:00                 ` Hao, Xudong
@ 2013-03-26 13:15                   ` Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 11+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-03-26 13:15 UTC (permalink / raw)
  To: Hao, Xudong
  Cc: 'keir@xen.org', 'Jan Beulich',
	'xen-devel@lists.xen.org'

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
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2013-03-26 13:15 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-22  7:48 [PATCH] xen/SandyBridge: reserve pages when integrated graphics Xudong Hao
2013-03-22 10:26 ` Jan Beulich
2013-03-23 14:51   ` Hao, Xudong
2013-03-25  9:28     ` Jan Beulich
2013-03-25  9:45       ` Hao, Xudong
2013-03-25  9:54         ` Jan Beulich
2013-03-25 12:39           ` Hao, Xudong
2013-03-25 13:06             ` Jan Beulich
2013-03-25 13:37               ` Hao, Xudong
2013-03-26  9:00                 ` Hao, Xudong
2013-03-26 13:15                   ` Konrad Rzeszutek Wilk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.