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

[y-oguchi@xxxxxxxxxxxxxx]

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