similar to: [PATCH 3/5] Paravirt smp.patch

Add VMI SMP boot hook. We emulate a regular boot sequence and use the same APIC IPI initiation, we just poke magic values to load into the CPU state when the startup IPI is received, rather than having to jump through a real mode trampoline. This is all that was needed to get SMP to work. Signed-off-by: Zachary Amsden <zach@vmware.com> Subject: SMP boot hook for paravirt diff -r

Add VMI SMP boot hook. We emulate a regular boot sequence and use the same APIC IPI initiation, we just poke magic values to load into the CPU state when the startup IPI is received, rather than having to jump through a real mode trampoline. This is all that was needed to get SMP to work. Signed-off-by: Zachary Amsden <zach@vmware.com> Subject: SMP boot hook for paravirt diff -r

The only member of that structure is startup_ipi_hook which is always set to paravirt_nop. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt.h | 9 --------- arch/x86/include/asm/paravirt_types.h | 10 ---------- arch/x86/include/asm/smp.h | 3 --- arch/x86/kernel/paravirt.c | 8 -------- arch/x86/kernel/smpboot.c

The only member of that structure is startup_ipi_hook which is always set to paravirt_nop. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt.h | 9 --------- arch/x86/include/asm/paravirt_types.h | 10 ---------- arch/x86/include/asm/smp.h | 3 --- arch/x86/kernel/paravirt.c | 8 -------- arch/x86/kernel/smpboot.c

SMP bootstrapping support. Just as in the physical platform model, the BSP is responsible for initializing the AP state prior to execution. The dependence on lots of processor state information is a design choice of our implementation. Conceivably, this could be a hypercall that awakens the same start of day state on APs as on the BSP. It is likely the AP startup and the start-of-day model will

SMP bootstrapping support. Just as in the physical platform model, the BSP is responsible for initializing the AP state prior to execution. The dependence on lots of processor state information is a design choice of our implementation. Conceivably, this could be a hypercall that awakens the same start of day state on APs as on the BSP. It is likely the AP startup and the start-of-day model will

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,

[ 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

Some of these boot hooks do not need to be patched, in fact, it is better not to patch them at all and thus keep them totally private. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r dba7b8b8e43d include/asm-i386/paravirt.h --- a/include/asm-i386/paravirt.h Thu Apr 19 16:12:02 2007 -0700 +++ b/include/asm-i386/paravirt.h Thu Apr 19 16:16:19 2007 -0700 @@ -686,12 +686,12 @@ static

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

Hello all, Here's a new version of the paravirt_ops x86_64 patch. With this message, I'm sending an incremental patch. The complete patches can be found , from now on, at http://et.redhat.com/~gcosta/paravirt_ops/ The main aim of this new update, is to fix a critical bug, namely, Rusty's name. However, I took the opportunity to write some new less important pieces of code,

Hello all, Here's a new version of the paravirt_ops x86_64 patch. With this message, I'm sending an incremental patch. The complete patches can be found , from now on, at http://et.redhat.com/~gcosta/paravirt_ops/ The main aim of this new update, is to fix a critical bug, namely, Rusty's name. However, I took the opportunity to write some new less important pieces of code,

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

The current paravirt startup_ipi hook for vmware commit: ae5da273fe3352febd38658d8d34484cbcfb3423 is quite frankly ridiculous. In the middle of wake_up_secondary_cpu: We have: /* * Paravirt / VMI wants a startup IPI hook here to set up the * target processor state. */ startup_ipi_hook(phys_apicid, (unsigned long) start_secondary, (unsigned