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 [y-oguchi] [Permanent Link][Original]
To: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0
From: y-oguchi@xxxxxxxxxxxxxx
Date: Fri, 06 Oct 2006 08:20:19 +0900
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Delivery-date: Thu, 05 Oct 2006 16:19:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <15C6E876552C98takebe_akio@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: <F5C6E6A7095382takebe_akio@xxxxxxxxxxxxxx> <EC6E84BEBE8A4takebe_akio@xxxxxxxxxxxxxx> <20061005075507.GA12156%yamahata@xxxxxxxxxxxxx> <20061005105708.GD12156%yamahata@xxxxxxxxxxxxx> <15C6E876552C98takebe_akio@xxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx 
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 0/3] p2m table exposure TAKE 2, Alex Williamson
Next by Date:  Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0, Akio Takebe
Previous by Thread:  Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0, Tristan Gingold
Next by Thread:  Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0, Akio Takebe
Indexes:  [Date] [Thread] [Top] [All Lists]
 
   

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