similar to: [PATCH 0/9] Bugfix patches for i386/vmi/paravirt-ops

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

These are the patches for the VMI backend to paravirt-ops. Base kernel where I tested them was 2.6.19-git20. Basically, there are only a couple of hooks needed that were left out of the initial paravirt-ops merge, and then the backend code is a very straightforward implementation of the paravirt-ops functions. Andrew or Linus, please apply or shoot me nasty feedback that I will promptly turn

These are the patches for the VMI backend to paravirt-ops. Base kernel where I tested them was 2.6.19-git20. Basically, there are only a couple of hooks needed that were left out of the initial paravirt-ops merge, and then the backend code is a very straightforward implementation of the paravirt-ops functions. Andrew or Linus, please apply or shoot me nasty feedback that I will promptly turn

VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted hypervisors will be. I have been working on a fix for this which works for older glibcs that panic when the new relocatable VDSO is used. However, I believe at this time that the fix is going to be too radical to consider at this stage in the release of 2.6.21. We don't expect this config option to be turned on by

VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted hypervisors will be. I have been working on a fix for this which works for older glibcs that panic when the new relocatable VDSO is used. However, I believe at this time that the fix is going to be too radical to consider at this stage in the release of 2.6.21. We don't expect this config option to be turned on by

More goo from hrtimers integration. We do compile and run properly with NO_HZ enabled. There was a period when we didn't because of a missing export, but that was since fixed. And with the clocksource code now firmly in place, we can get rid of code that fixes up the wallclock, since this is done in the common infrastructure. This actually fixes a timer bug as well, that was caused by

More goo from hrtimers integration. We do compile and run properly with NO_HZ enabled. There was a period when we didn't because of a missing export, but that was since fixed. And with the clocksource code now firmly in place, we can get rid of code that fixes up the wallclock, since this is done in the common infrastructure. This actually fixes a timer bug as well, that was caused by

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

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

The custom_sched_clock hook is broken. The result from sched_clock needs to be in nanoseconds, not in CPU cycles. The TSC is insufficient for this purpose, because TSC is poorly defined in a virtual environment, and mostly represents real world time instead of scheduled process time (which can be interrupted without notice when a virtual machine is descheduled). To make the scheduler

The custom_sched_clock hook is broken. The result from sched_clock needs to be in nanoseconds, not in CPU cycles. The TSC is insufficient for this purpose, because TSC is poorly defined in a virtual environment, and mostly represents real world time instead of scheduled process time (which can be interrupted without notice when a virtual machine is descheduled). To make the scheduler

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