similar to: [PATCH 0/3] VMI hotfixes

Now that Jeremy's change to move the kernel PDA to %fs has arrived, convert the AP processor setup for SMP to use FS instead of GS. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 2ac108843573 arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.c Thu Jan 04 20:01:52 2007 -0800 +++ b/arch/i386/kernel/vmi.c Thu Jan 04 20:02:42 2007 -0800 @@ -533,8 +533,8 @@ vmi_startup_ipi_hook(int

Now that Jeremy's change to move the kernel PDA to %fs has arrived, convert the AP processor setup for SMP to use FS instead of GS. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 2ac108843573 arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.c Thu Jan 04 20:01:52 2007 -0800 +++ b/arch/i386/kernel/vmi.c Thu Jan 04 20:02:42 2007 -0800 @@ -533,8 +533,8 @@ vmi_startup_ipi_hook(int

VMI backend for paravirt-ops; fairly straightforward drop-in to paravirt-ops. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance significantly. However, when

VMI backend for paravirt-ops; fairly straightforward drop-in to paravirt-ops. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance significantly. However, when

Fairly straightforward implementation of VMI backend for paravirt-ops. Subject: VMI backend for paravirt-ops Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance

Fairly straightforward implementation of VMI backend for paravirt-ops. Subject: VMI backend for paravirt-ops Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r d8711b11c1eb arch/i386/Kconfig --- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800 +++ b/arch/i386/Kconfig Tue Dec 12 13:51:13 2006 -0800 @@ -192,6 +192,15 @@ config PARAVIRT under a hypervisor, improving performance

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

Provide a PT map hook for HIGHPTE kernels to designate where they are mapping page tables. This information is required so the physical address of PTE updates can be determined; otherwise, the mm layer would have to carry the physical address all the way to each PTE modification callsite, which is even more hideous that the macros required to provide the proper hooks. So lets not mess up arch

Provide a PT map hook for HIGHPTE kernels to designate where they are mapping page tables. This information is required so the physical address of PTE updates can be determined; otherwise, the mm layer would have to carry the physical address all the way to each PTE modification callsite, which is even more hideous that the macros required to provide the proper hooks. So lets not mess up arch

Now that the VDSO can be relocated, we can support it in VMI configurations. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 158d9ffb46fe arch/i386/Kconfig --- a/arch/i386/Kconfig Thu Mar 29 04:17:05 2007 -0700 +++ b/arch/i386/Kconfig Thu Mar 29 04:18:05 2007 -0700 @@ -220,7 +220,7 @@ config PARAVIRT config VMI bool "VMI Paravirt-ops support" - depends on PARAVIRT

Now that the VDSO can be relocated, we can support it in VMI configurations. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 158d9ffb46fe arch/i386/Kconfig --- a/arch/i386/Kconfig Thu Mar 29 04:17:05 2007 -0700 +++ b/arch/i386/Kconfig Thu Mar 29 04:18:05 2007 -0700 @@ -220,7 +220,7 @@ config PARAVIRT config VMI bool "VMI Paravirt-ops support" - depends on PARAVIRT

In paravirt builds with VMI compiled in, vmi_bringup is called unconditionally, not via a paravirt-ops table (as no other hypervisor uses the APIC startup technique). Make the calls to setup VMI state conditional on the presence of the VMI ROM. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1915e2685a3c arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.c Thu Jan 04 15:56:40 2007

In paravirt builds with VMI compiled in, vmi_bringup is called unconditionally, not via a paravirt-ops table (as no other hypervisor uses the APIC startup technique). Make the calls to setup VMI state conditional on the presence of the VMI ROM. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1915e2685a3c arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.c Thu Jan 04 15:56:40 2007

In order to share the common code in tsc.c which does CPU Khz calibration, we need to make an accurate value of CPU speed available to the tsc.c code. This value loses a lot of precision in a VM because of the timing differences with real hardware, but we need it to be as precise as possible so the guest can make accurate time calculations with the cycle counters. Signed-off-by: Zachary Amsden

In order to share the common code in tsc.c which does CPU Khz calibration, we need to make an accurate value of CPU speed available to the tsc.c code. This value loses a lot of precision in a VM because of the timing differences with real hardware, but we need it to be as precise as possible so the guest can make accurate time calculations with the cycle counters. Signed-off-by: Zachary Amsden

Code changes and cleanup in the paravirt-ops queue caused the original fix for this in 2.6.21 to create conflicts. The easiest thing to do was back it out before applying the queue. In that case, this fix brings it back with the newly right properly tidied up paravirt-ops code. Wheee! Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r ecb571084874 arch/i386/kernel/vmi.c ---

Code changes and cleanup in the paravirt-ops queue caused the original fix for this in 2.6.21 to create conflicts. The easiest thing to do was back it out before applying the queue. In that case, this fix brings it back with the newly right properly tidied up paravirt-ops code. Wheee! Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r ecb571084874 arch/i386/kernel/vmi.c ---

So it's gotten a bit confusing to figure out how we should go about upstreaming the rest of our patches. Our patchkit in the paravirt-ops tree currently applies to 2.6.19-rc4-mm2, but there are a number of conflicts that got resolved when merging into Andi's i386 tree. What is the best way to sanitize the remaining patches so they smoothly integrate into the appropriate trees?

So it's gotten a bit confusing to figure out how we should go about upstreaming the rest of our patches. Our patchkit in the paravirt-ops tree currently applies to 2.6.19-rc4-mm2, but there are a number of conflicts that got resolved when merging into Andi's i386 tree. What is the best way to sanitize the remaining patches so they smoothly integrate into the appropriate trees?