similar to: Xen/paravirt_ops kernel available for testing

Make paravirt-ops be a pure function pointer struct; we already have assembly code which uses arithmetic by 4 bytes, which means arbitrary structures are not possible here, and they are not needed. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r a6889086a657 arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Thu Apr 19 15:44:49 2007 -0700 +++

Make paravirt-ops be a pure function pointer struct; we already have assembly code which uses arithmetic by 4 bytes, which means arbitrary structures are not possible here, and they are not needed. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r a6889086a657 arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Thu Apr 19 15:44:49 2007 -0700 +++

Subject: Add a sched_clock paravirt_op The tsc-based get_scheduled_cycles interface is not a good match for Xen's runstate accounting, which reports everything in nanoseconds. This patch replaces this interface with a sched_clock interface, which matches both Xen and VMI's requirements. In order to do this, we: 1. replace get_scheduled_cycles with sched_clock 2. hoist cycles_2_ns

Subject: Add a sched_clock paravirt_op The tsc-based get_scheduled_cycles interface is not a good match for Xen's runstate accounting, which reports everything in nanoseconds. This patch replaces this interface with a sched_clock interface, which matches both Xen and VMI's requirements. In order to do this, we: 1. replace get_scheduled_cycles with sched_clock 2. hoist cycles_2_ns

If you are interested in trying the new paravirt_ops kernels, I've created some packages and uploaded them to: http://et.redhat.com/~chrisw/paravirt_ops/ There you'll find a yum repo (see yum.README for details) and an INSTALL file for getting started. With this package you can use a single kernel[1] for both native (w/out a hypervisor, or under a full virt hypervisor), domU paravirt

If you are interested in trying the new paravirt_ops kernels, I've created some packages and uploaded them to: http://et.redhat.com/~chrisw/paravirt_ops/ There you'll find a yum repo (see yum.README for details) and an INSTALL file for getting started. With this package you can use a single kernel[1] for both native (w/out a hypervisor, or under a full virt hypervisor), domU paravirt

If you are interested in trying the new paravirt_ops kernels, I've created some packages and uploaded them to: http://et.redhat.com/~chrisw/paravirt_ops/ There you'll find a yum repo (see yum.README for details) and an INSTALL file for getting started. With this package you can use a single kernel[1] for both native (w/out a hypervisor, or under a full virt hypervisor), domU paravirt

If you are interested in trying the new paravirt_ops kernels, I've created some packages and uploaded them to: http://et.redhat.com/~chrisw/paravirt_ops/ There you'll find a yum repo (see yum.README for details) and an INSTALL file for getting started. With this package you can use a single kernel[1] for both native (w/out a hypervisor, or under a full virt hypervisor), domU paravirt

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

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

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

Hi all, The next obvious step for paravirt_ops seems to me to be higher-level mmu operations: from reading the VMI patches it seems to do flushing, whereas Xen opts for batching. In the spirit of ops structures, this would be done by putting higher-level operations into the ops structure, and batching done by the op itself (perhaps with a default implementation for those too lazy to implement

Hi all, The next obvious step for paravirt_ops seems to me to be higher-level mmu operations: from reading the VMI patches it seems to do flushing, whereas Xen opts for batching. In the spirit of ops structures, this would be done by putting higher-level operations into the ops structure, and batching done by the op itself (perhaps with a default implementation for those too lazy to implement

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,