On Mon, Jan 07, 2013 at 09:48:20AM +0000, Jan Beulich wrote:
quoted
quoted
quoted
On 04.01.13 at 18:25, Daniel Kiper [off-list ref] wrote:
Right, so where is virtual mapping of control page established?
I could not find relevant code in SLES kernel which does that.
In the hypervisor (xen/arch/x86/machine_kexec.c:machine_kexec_load()).
xen/arch/x86/machine_kexec.c:machine_kexec() then simply uses
image->page_list[1].
This (xen/arch/x86/machine_kexec.c:machine_kexec_load()) maps relevant
page (allocated earlier by dom0) in hypervisor fixmap area. However,
it does not make relevant mapping in transition page table which
leads to crash when %cr3 is switched from Xen page table to
transition page table.
Daniel
quoted
quoted
On 07.01.13 at 13:52, Daniel Kiper [off-list ref] wrote:
On Mon, Jan 07, 2013 at 09:48:20AM +0000, Jan Beulich wrote:
quoted
quoted
quoted
quoted
On 04.01.13 at 18:25, Daniel Kiper [off-list ref] wrote:
Right, so where is virtual mapping of control page established?
I could not find relevant code in SLES kernel which does that.
In the hypervisor (xen/arch/x86/machine_kexec.c:machine_kexec_load()).
xen/arch/x86/machine_kexec.c:machine_kexec() then simply uses
image->page_list[1].
This (xen/arch/x86/machine_kexec.c:machine_kexec_load()) maps relevant
page (allocated earlier by dom0) in hypervisor fixmap area. However,
it does not make relevant mapping in transition page table which
leads to crash when %cr3 is switched from Xen page table to
transition page table.
That indeed could explain _random_ failures - the fixmap entries
get created with _PAGE_GLOBAL set, i.e. don't get flushed with
the CR3 write unless CR4.PGE is clear.
And I don't see how your allocation of intermediate page tables
would help: You wouldn't know where the mapping of the control
page lives until you're actually in the early relocate_kernel code.
Or was it that what distinguishes your cloned code from the
native original?
Jan
On Mon, Jan 07, 2013 at 01:05:10PM +0000, Jan Beulich wrote:
quoted
quoted
quoted
On 07.01.13 at 13:52, Daniel Kiper [off-list ref] wrote:
On Mon, Jan 07, 2013 at 09:48:20AM +0000, Jan Beulich wrote:
quoted
quoted
quoted
quoted
On 04.01.13 at 18:25, Daniel Kiper [off-list ref] wrote:
Right, so where is virtual mapping of control page established?
I could not find relevant code in SLES kernel which does that.
In the hypervisor (xen/arch/x86/machine_kexec.c:machine_kexec_load()).
xen/arch/x86/machine_kexec.c:machine_kexec() then simply uses
image->page_list[1].
This (xen/arch/x86/machine_kexec.c:machine_kexec_load()) maps relevant
page (allocated earlier by dom0) in hypervisor fixmap area. However,
it does not make relevant mapping in transition page table which
leads to crash when %cr3 is switched from Xen page table to
transition page table.
That indeed could explain _random_ failures - the fixmap entries
get created with _PAGE_GLOBAL set, i.e. don't get flushed with
the CR3 write unless CR4.PGE is clear.
This does not matter. As I stated earlier virtual mapping is wrong.
relocate_kernel() is mapped at its virtual address in Linux kernel
instead of control page at its virtual address in Xen hypervisor.
I tested SLES kernel once again. It does not work.
And I don't see how your allocation of intermediate page tables
would help: You wouldn't know where the mapping of the control
page lives until you're actually in the early relocate_kernel code.
Right. Allocation itself is not a solution for this problem.
It should be acompanied by code which establishes transition
page table in relocate_kernel() (which is later copied
to control page, i.e. code of relocate_kernel()).
Or was it that what distinguishes your cloned code from the
native original?
No, my code is based on native original.
There are some implementation differences.
Daniel