Re: 2.6.25-rc1 xen pvops regression
From: H. Peter Anvin
Date: Thu Feb 21 2008 - 16:27:32 EST
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/