similar to: [PATCH 0/6] VMI paravirt-ops patches

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

Andi, Linus, we have some critical bugfixes for the VMI paravirt-ops code. Please apply. If there are objections to certain pieces, they can be reworked, but they are pretty much all needed for correctness. We are hoping to get these in the next 2.6.21-rc release. We had quite a few difficulties debugging after the integration of the hrtimers code, which is why this took so long. Andrew, add

Andi, Linus, we have some critical bugfixes for the VMI paravirt-ops code. Please apply. If there are objections to certain pieces, they can be reworked, but they are pretty much all needed for correctness. We are hoping to get these in the next 2.6.21-rc release. We had quite a few difficulties debugging after the integration of the hrtimers code, which is why this took so long. Andrew, add

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?

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

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

So there is a logic error that would prevent us from ever using NOP = relocations, thus stopping any unnecessary callouts into a VMI ROM. It = doesn't affect us so much, but could conceivably affect open source = implementations of a VMI ROM in the future. It is not absolutely = critical, but it would be extremely nice to get it fixed in 2.6.21 so = there are no broken older kernels

So there is a logic error that would prevent us from ever using NOP = relocations, thus stopping any unnecessary callouts into a VMI ROM. It = doesn't affect us so much, but could conceivably affect open source = implementations of a VMI ROM in the future. It is not absolutely = critical, but it would be extremely nice to get it fixed in 2.6.21 so = there are no broken older kernels

Fairly straightforward code motion of MSR / TSC / PMC accessors to the sub-arch level. Note that rdmsr/wrmsr_safe functions are not moved; Linux relies on the fault behavior here in the event that certain MSRs are not supported on hardware, and combining this with a VMI wrapper is overly complicated. The instructions are virtualizable with trap and emulate, not on critical code paths, and only

Fairly straightforward code motion of MSR / TSC / PMC accessors to the sub-arch level. Note that rdmsr/wrmsr_safe functions are not moved; Linux relies on the fault behavior here in the event that certain MSRs are not supported on hardware, and combining this with a VMI wrapper is overly complicated. The instructions are virtualizable with trap and emulate, not on critical code paths, and only

Master definition of VMI interface, including calls, constants, and interface version. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/include/asm-i386/mach-vmi/paravirtualInterface.h =================================================================== --- linux-2.6.16-rc5.orig/include/asm-i386/mach-vmi/paravirtualInterface.h 2006-03-08 10:08:45.000000000 -0800 +++

Master definition of VMI interface, including calls, constants, and interface version. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/include/asm-i386/mach-vmi/paravirtualInterface.h =================================================================== --- linux-2.6.16-rc5.orig/include/asm-i386/mach-vmi/paravirtualInterface.h 2006-03-08 10:08:45.000000000 -0800 +++

Fix reboot to work with the VMI. We must support fallback to the standard BIOS reboot mechanism. Turns out that this is required by kexec, and a good idea for native hardware. We simply insert the NOP VMI reboot hook before calling the BIOS reboot. While here, fix SMP reboot issues as well. The problem is the halt() macro in VMI has been defined to be equivalent to safe_halt(), which enables

Fix reboot to work with the VMI. We must support fallback to the standard BIOS reboot mechanism. Turns out that this is required by kexec, and a good idea for native hardware. We simply insert the NOP VMI reboot hook before calling the BIOS reboot. While here, fix SMP reboot issues as well. The problem is the halt() macro in VMI has been defined to be equivalent to safe_halt(), which enables

Add a /proc node for the VMI sub-arch, which gives information on the VMI ROM detected using /proc/vmi/info and a list of kernel annotations in /proc/vmi/annotations. The timing information is VMware specific, and should probably be put into a separate /proc node (and a separate patch for our internal use). Signed-off-by: Zachary Amsden <zach@vmware.com> Index:

Add a /proc node for the VMI sub-arch, which gives information on the VMI ROM detected using /proc/vmi/info and a list of kernel annotations in /proc/vmi/annotations. The timing information is VMware specific, and should probably be put into a separate /proc node (and a separate patch for our internal use). Signed-off-by: Zachary Amsden <zach@vmware.com> Index: