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.
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?
Option C or A.3 is preferable. I don't think those are
ery good, though. Any ideas?
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home