The small fix is just changing the magic number in setup_var_mtrrs():
diff -r 5b25d3264f7e xen/arch/x86/hvm/mtrr.c
--- a/xen/arch/x86/hvm/mtrr.c Wed Apr 09 17:49:25 2008 +0100
+++ b/xen/arch/x86/hvm/mtrr.c Thu Apr 10 10:40:56 2008 +0800
@@ -266,7 +266,7 @@ static void setup_var_mtrrs(struct vcpu
{
if ( e820_table[i].addr == 0x100000 )
{
- size = e820_table[i].size + 0x100000 + PAGE_SIZE * 4;
+ size = e820_table[i].size + 0x100000 + PAGE_SIZE * 5;
addr = 0;
}
else
Disheng, do you have any good idea?
Randy (Weidong)
Keir Fraser wrote:> But that''s an existing range that is extended, rather than a new
> range being declared. So how come the MTRR code gets confused?
>
> Anyway, its days are numbered since I plan to move it out into
> hvmloader. But please send a fix for now.
>
> -- Keir
>
> On 10/4/08 09:33, "Han, Weidong" <weidong.han@intel.com>
wrote:
>
>> Due to c/s 17404 reserves one more special page in build_e820map(),
>> MTRR can''t cover all memory ranges. In order to fix it, need
to do
>> relevant changing in setup_var_mtrrs() which uses magic number to
>> caculate size. It''s the second time this issue occurs.
It''s better
>> to get rid the magic number. Thanks!
>>
>> Randy (Weidong)
>>
>> _______________________________________________
>> Xen-devel mailing listcd
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel