"H. Peter Anvin" <hpa@zytor.com> writes:

quoted text
> 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?

The immediate symptom was that we have a page table at the address we
are doing the DMI probe.  Xen does not allow pages tables to be mapped
read-write so early_ioremap get into trouble.

We have a mystery:
- Why did the Xen domain builder or the linux kernel use 0xf0000 - 0x10000
  for a page table.

  It should be possible to instrument the early linux page allocation
  and see what page pages linux is using to see who is doing weird
  things.

We have possible solutions.
- Add a read-only flag to early_ioremap for use by our table scans.
- Don't do a DMI scan in the case of Xen.
- Fix the Xen domain builder.

My inclination is that we disable the fruitless DMI scan in the case
Xen, or we get the Xen domain builder fixed.

If Xen is going to increasingly look like a normal X86 BIOS we should
let the DMI scan run and be put the burden on Xen to keep things
looking like a normal x86 machine.  If Xen is not going to look more
like a normal x86 machine we can say oh, that is nice, it's Xen so
don't bother doing things that will cause problems.

In this case can we confirm that the domain builder is using those
early 64k as pages for a page table, and then educate it that not
allowing OS access to those pages is a little silly.

All of that said.  For DMI tables other early tables we should not
be writing to them anyway so learning to use read-only maps may be
the right solution.  If the reason Xen was complaining was that
we were accessing an area that was not page tables but instead
should only be mapped read-only I would have a lot of sympathy
with that.  As mapping areas that are architecturally ROMs read-write
is silly.

So guys can you please finish the root cause and really see why there
is a page table page at in 64K ROM BIOS area?

Eric
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/