Re: 2.6.25-rc1 xen pvops regression

[Jeremy Fitzhardinge <jeremy@goop.org>]

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?

    J