WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 		  
Home Products Support Community News
 
   
 

xen-ia64-devel

[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0

from [Akio Takebe] [Permanent Link][Original]
To: y-oguchi@xxxxxxxxxxxxxx, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0
From: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
Date: Fri, 06 Oct 2006 09:37:45 +0900
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Delivery-date: Thu, 05 Oct 2006 17:40:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <JN20061006082019580.674505218@xxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20061005075507.GA12156%yamahata@xxxxxxxxxxxxx> <20061005105708.GD12156%yamahata@xxxxxxxxxxxxx> <15C6E876552C98takebe_akio@xxxxxxxxxxxxxx> <JN20061006082019580.674505218@xxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx 
Hi, Isaku and Yoshi

I'm sorry, I misread Isaku's mail.

modular vnif(and xenblk) had two problem.
1. Allocating big order pages by using alloc_page().
   This issue is no problem when vnif is not module,
   because the alloc_page() success at very early boot time.
   But in the case of modular vnif, this issue is happened,
   because the fragmentation is happened at late boot time.
   
   Juan said "Why does ia64 give only 512M to dom0 instead 
   of doing the same as x86?
   So I made the allocate_allmemory.patch.
   Then I found this problem.
   
2. Don't work copy_from/to_user().
   this issue is fixed by Tristan's xencomm patches.
   This allocation problem is not relevant to copy_from/to_user problem.
   This issue is not happened again because Tristan's patches 
   was merged.
   
Best Regards,

Akio Takebe

>Akio, Isaku
>
>> >  The original motivation is to get modular vnif work.
>> >  Now xencomm has been merged, this isn't an issue anymore.
>> >  Akio, Is this right?
>> >
>> Yes, you are right.
>> I have not tried to check modular vnif yet.
>> But I have checked it with cset 11635 + Tristan's xen-xcom-[a-c]3.
>diffs.
>> The results is good work.
>
>I'm a bit confused.
>
>I thought Akio's issue is related to vnif backend's allocation failure 
>(order=8 request), so, I don't understand why xencom patch resolved the 
>issue.
>
>Could you explain why?, sorry for my ignorance.
>
>Thanks,
>Yoshi
>
>Akio Takebe <takebe_akio@xxxxxxxxxxxxxx> wrote：
>> Hi, Isaku and Tristan
>> 
>> Thank you for your comments.
>> >
>> >On Thu, Oct 05, 2006 at 04:55:07PM +0900, Isaku Yamahata wrote:
>> >> On Thu, Oct 05, 2006 at 04:00:20PM +0900, Akio Takebe wrote:
>> >> > Hi,
>> >> > 
>> >> > Also in the case of current Xen-ia64-unstable(cset:11721),
>> >> > this panic is occured by specified dom0_mem=4G.
>> >> > (without my patch)
>> >> > 
>> >> > I think the following error message is hint of this bug.
>> >> > (XEN) Warning: UC to WB for mpaddr=f9ff0000
>> >> > 
>> >> > I checked the arch/ia64/xen/mm.c
>> >> > Why changing pteval2 from UC to WB is OK?
>> >> > If pteval2 is WB and pteval is UC, should pteval2 be changed to 
>UC?
>> >> > 
>> >> 
>> >> Because it's RAM. not I/O.
>> >> >From your log
>> >> > (XEN) dom mem: type= 7, attr=0x0000000000000008, range=
>> >> > [0x0000000080000000-0x00000000fe000000) (2016MB)
>> >> Probably ioremap hypercall failed.
>> >> Please check it by adding debug message assign_domain_same_page().
>> >> I suppose it should complain somehow.
>> >> 
>> >> 
>> >> The warning message is the result of Linux tries to use the 
>addresses
>> >> for I/O which is RAM.
>> >> Then the next question is why/how Linux decided to use the 
>addresses
>> >> to map I/O.
>> >> iomem_resource manages those regions so that such a overlap
>> >> shouldn't happen.
>> >
>> >This is wrong. Linux doesn't complain.
>> >Dom0 builder assigns RAM which overlaps with PCI I/O so that
>> >dom0Linux can't access PCI devices.
>> >So far no one has assigned so much memory to dom0, 
>> >this wasn't an issue.
>> 
>> Thank you for your infomation!.
>> I checked Linux /proc/iomem. You are right.
>> # cat /proc/iomem 
>> [snip..]
>>     f8e00000-f8efffff : 0000:06:02.1
>>     f8fc0000-f8fcffff : 0000:06:02.0
>>     f8fd0000-f8fdffff : 0000:06:02.0
>>     f8fe0000-f8feffff : 0000:06:02.1
>>     f8ff0000-f8ffffff : 0000:06:02.1
>> f9000000-fbffffff : PCI Bus 0000:00 <-----------this
>>   f9ff0000-f9ff03ff : 0000:00:1d.7
>>     f9ff0000-f9ff03ff : ehci_hcd
>>   fa000000-fbffffff : PCI Bus #01
>>     fa000000-faffffff : 0000:01:01.0
>>     
>>     
>> And the below is dom0 map at dom0_mem=2G and dom0_mem=4G.
>> dom0_mem=4G
>> (XEN) dom mem: type=13, attr=0x8000000000000008, range=
>[0x0000000000000000-0x0000000000001000) (4KB)
>> (XEN) dom mem: type=10, attr=0x8000000000000008, range=
>[0x0000000000001000-0x0000000000002000) (4KB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000008, range=
>[0x0000000000002000-0x0000000000003000) (4KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000003000-0x0000000000007000) (16KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000007000-0x0000000000009000) (8KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000009000-0x0000000000082000) (484KB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000009, range=
>[0x0000000000082000-0x0000000000084000) (8KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000084000-0x0000000000085000) (4KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000085000-0x00000000000a0000) (108KB)
>> (XEN) dom mem: type= 5, attr=0x8000000000000009, range=
>[0x00000000000c0000-0x0000000000100000) (256KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000008, range=
>[0x0000000000100000-0x000000007f708000) (2038MB)
>> (XEN) dom mem: type= 5, attr=0x8000000000000009, range=
>[0x000000007f70a000-0x000000007fb00000) (3MB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000008, range=
>[0x000000007fb00000-0x000000007fe00000) (3MB)
>> (XEN) dom mem: type= 5, attr=0x8000000000000009, range=
>[0x000000007fe00000-0x000000007fe58000) (352KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000008, range=
>[0x000000007fe58000-0x000000007feb8000) (384KB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000009, range=
>[0x000000007feba000-0x0000000080000000) (1MB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000008, range=
>[0x0000000080000000-0x00000000fe000000) (2016MB)
>> (XEN) dom mem: type=11, attr=0x0000000000000001, range=
>[0x00000000fe000000-0x00000000ff000000) (16MB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000001, range=
>[0x00000000ff000000-0x0000000100000000) (16MB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000009, range=
>[0x00000001ffffe000-0x0000000200000000) (8KB)
>> (XEN) dom mem: type= 5, attr=0x8000000000000009, range=
>[0x00000002ffe14000-0x00000002ffe80000) (432KB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000009, range=
>[0x00000002fffb8000-0x0000000300000000) (288KB)
>> (XEN) dom mem: type=11, attr=0x8000000000000001, range=
>[0x00000ffff8000000-0x00000ffffc000000) (64MB)
>> (XEN) dom mem: type=12, attr=0x8000000000000001, range=
>[0x00000ffffc000000-0x0000100000000000) (64MB)
>> 
>> 
>> dom0_mem=2G
>> (XEN) dom mem: type=13, attr=0x8000000000000008, range=
>[0x0000000000000000-0x0000000000001000) (4KB)
>> (XEN) dom mem: type=10, attr=0x8000000000000008, range=
>[0x0000000000001000-0x0000000000002000) (4KB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000008, range=
>[0x0000000000002000-0x0000000000003000) (4KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000003000-0x0000000000007000) (16KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000007000-0x0000000000009000) (8KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000009000-0x0000000000082000) (484KB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000009, range=
>[0x0000000000082000-0x0000000000084000) (8KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000084000-0x0000000000085000) (4KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000009, range=
>[0x0000000000085000-0x00000000000a0000) (108KB)
>> (XEN) dom mem: type= 5, attr=0x8000000000000009, range=
>[0x00000000000c0000-0x0000000000100000) (256KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000008, range=
>[0x0000000000100000-0x000000007f708000) (2038MB)
>> (XEN) dom mem: type= 5, attr=0x8000000000000009, range=
>[0x000000007f70a000-0x000000007fb00000) (3MB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000008, range=
>[0x000000007fb00000-0x000000007fe00000) (3MB)
>> (XEN) dom mem: type= 5, attr=0x8000000000000009, range=
>[0x000000007fe00000-0x000000007fe58000) (352KB)
>> (XEN) dom mem: type= 7, attr=0x0000000000000008, range=
>[0x000000007fe58000-0x000000007feb8000) (384KB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000009, range=
>[0x000000007feba000-0x0000000080000000) (1MB)
>> (XEN) dom mem: type=11, attr=0x0000000000000001, range=
>[0x00000000fe000000-0x00000000ff000000) (16MB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000001, range=
>[0x00000000ff000000-0x0000000100000000) (16MB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000009, range=
>[0x00000001ffffe000-0x0000000200000000) (8KB)
>> (XEN) dom mem: type= 5, attr=0x8000000000000009, range=
>[0x00000002ffe14000-0x00000002ffe80000) (432KB)
>> (XEN) dom mem: type= 6, attr=0x8000000000000009, range=
>[0x00000002fffb8000-0x0000000300000000) (288KB)
>> (XEN) dom mem: type=11, attr=0x8000000000000001, range=
>[0x00000ffff8000000-0x00000ffffc000000) (64MB)
>> (XEN) dom mem: type=12, attr=0x8000000000000001, range=
>[0x00000ffffc000000-0x0000100000000000) (64MB)
>> 
>> 
>> 
>> 
>> >
>> >I think there are two right way.
>> >A avoid overlap somehow
>> >  A.0 fake up ACPI table and assign pci somewhere.
>> >  A.1 detect pci bridge
>> >      To detect the region of pci bridge, it is necessary to parse
>> >      ACPI table. But xen doesn't have such a ACPI parser.
>> >  A.2 As a temporal work around, we can introduce xen boot option to
>> >      indicate pci io area.
>> >  A.3 assign RAM following the original MD.
>> >      This might be easy.
>> >      The current complete_dom0_memmap() seeks a gap and fill it
>> >      with RAM. modify it so that it only assigns RAM only when
>> >      a found gap is in baremetal's RAM.
>> >B modify ioremap hypercall and linux ioremap somehow 
>> >  to not use ram region.
>> >  Probably Linux ioremap() wouldn't return __IA64_UNCACHED_OFFSET|
>offset
>> >  so that iounmap() might need to be implemented.
>> >C don't give so much memory to dom0
>> >  The original motivation is to get modular vnif work.
>> >  Now xencomm has been merged, this isn't an issue anymore.
>> >  Akio, Is this right?
>> >
>> Yes, you are right.
>> I have not tried to check modular vnif yet.
>> But I have checked it with cset 11635 + Tristan's xen-xcom-[a-c]3.
>diffs.
>> The results is good work.
>> 
>> 
>> >Option C or A.3 is preferable. I don't think those are 
>> >ery good, though. Any ideas?
>> >
>> I also prefer A.3 to others.
>> 
>> Best Regards,
>> 
>> Akio Takebe
>> 
>> 
>> _______________________________________________
>> Xen-ia64-devel mailing list
>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-ia64-devel



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0, y-oguchi
Next by Date:  [Xen-ia64-devel] [PATCH] fix dom0 builder, Isaku Yamahata
Previous by Thread:  Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0, y-oguchi
Next by Thread:  [Xen-devel] [PATCH] make MAX_SKBUFF_ORDER page size independent, Isaku Yamahata
Indexes:  [Date] [Thread] [Top] [All Lists]
 
   

Copyright , Citrix Systems Inc. All rights reserved. Legal and Privacy