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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.03.13 at 10:45, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Monday, March 25, 2013 5:28 PM
>> To: Hao, Xudong
>> Cc: xen-devel@xxxxxxxxxxxxx; keir@xxxxxxx 
>> Subject: RE: [PATCH] xen/SandyBridge: reserve pages when integrated graphics
>> 
>> >>> On 23.03.13 at 15:51, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
>> >>  -----Original Message-----
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Friday, March 22, 2013 6:27 PM
>> >> To: Hao, Xudong
>> >> Cc: xen-devel@xxxxxxxxxxxxx; keir@xxxxxxx 
>> >> Subject: Re: [PATCH] xen/SandyBridge: reserve pages when integrated
>> graphics
>> >>
>> >> >>> On 22.03.13 at 08:48, Xudong Hao <xudong.hao@xxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel