All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Xudong Hao <xudong.hao@intel.com>
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
Date: Fri, 22 Mar 2013 10:26:48 +0000	[thread overview]
Message-ID: <514C3FF802000078000C7B28@nat28.tlf.novell.com> (raw)
In-Reply-To: <1363938487-11153-1-git-send-email-xudong.hao@intel.com>

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

  reply	other threads:[~2013-03-22 10:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-22  7:48 [PATCH] xen/SandyBridge: reserve pages when integrated graphics Xudong Hao
2013-03-22 10:26 ` Jan Beulich [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=514C3FF802000078000C7B28@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.org \
    --cc=xudong.hao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.