Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.

[Eric W. Biederman]

"H. Peter Anvin" <hpa@xxxxxxxxx> writes:

> Jeremy Fitzhardinge wrote:
>> H. Peter Anvin wrote:
>>> No, if Xen wasn't an issue there wouldn't be anything to do for the PAE case
>>> at all (since the PGD is trivial.)
>>>
>>> Copying PMDs is more or less an analogous case of the !PAE case, once the
>>> allocation is already done.  The allocation should be trivial though, since
>>> this would be a one-time thing.
>>
>> I think we're in vehement agreement here.  In either case, its just a matter
>> of something like:
>>
>>    memcpy(pgd, &pgd[USER_PTRS_PER_PGD], sizeof(pgd_t) * KERNEL_PTRS_PER_PGD);
>>     which would work for both PAE and non-PAE.
>>
>>>> It would be easy enough to add some code on xen side to look for pmd aliases
>>>> when using/pinning a pagetable, and allocate'n'copy a new pmd page as
>>>> needed.  That way the core code can ignore the issue.
>>>
>>> As much as I'd rather see Xen fixing this than having it continue to impact
>>> the kernel, I presume it will take some time to flush the broken hypervisors
>>> out?
>>
>> Sorry, I was unclear.  I meant in the purely Xen-specific parts of the kernel
>> (arch/x86/xen).  It wouldn't require a hypervisor change.
>>
>
> Oh, that makes that option much more viable and probably preferrable.

Note.  I don't believe we use either trampoline (cpu startup or acpi wakeup)
in the hypervisor case (esp Xen).  So we should be able to completely ignore
Xen and do the memcpy of pgd entries.

I expect Xen gives us other cpus already in protected mode (which is overall
the sane thing to do).

Eric
--
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/