Messages in this thread | | | Date | Thu, 21 Feb 2008 13:21:27 -0800 | From | "H. Peter Anvin" <> | Subject | Re: 2.6.25-rc1 xen pvops regression |
| |
Jeremy Fitzhardinge wrote: > Ian Campbell wrote: >> I'll see if I can track down where the page is getting used and have a >> go at getting in there first. It must be pretty early to be allocated >> already when dmi_scan_machine gets called. >> >> It's possible that the domain builder might have already allocated a PT >> at this address. I haven't checked but I think currently the domain >> builder always puts PT pages after the kernel so hopefully it's only a >> theoretical problem. >> > > Yes, it does. And presumably the early pagetable builder is guaranteed > to avoid special memory like the DMI space. But the bug definitely > seems to be a result of the DMI code trying to make a RW mapping of a > pagetable page, so something is amiss there. > > Ooh, sleazy hack idea: make DMI always map RO, so even if it does get a > pagetable it causes no complaint... A bit awkward, since there doesn't > seem to be an RO form of early_ioremap. > >> Another option I was thinking of was a command line option to disable >> DMI, which (maybe) isn't terribly useful in itself but it introduces an >> associated variable to frob with. That's similar to how the TSC was >> handled in the past (well, the opposite since TSC was forced on). >> > > Yep, that would work too. > > Still curious about why a pagetable page is ending up in that range > though. Seems like it shouldn't be possible, since we shouldn't be > allowed to allocate from those pages, at least until the DMI probe has > happened... Unless the early allocator is only excluded from e820 > reserved pages, which would cause a problem on systems which don't > reserve the DMI space... HPA? >
I thought the problem was a Xen-provided pagetable from before Linux started?
-hpa
| |