search for: vsmp

Change Makefile so vsmp_64.o object is dependent on PARAVIRT, rather than X86_VSMP Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ravikiran Thirumalai <kiran@scalemp.com> Acked-by: Shai Fultheim <shai@scalemp.com> --- arch/x86/kernel/Makefile | 2 +- 1 files changed, 1 insertions(+)...

On Tue, 11 Mar 2008 01:14:34 -0700 Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc5/2.6.25-rc5-mm1/ randconfig (x86_64) with PCI=n PARAVIRT=y VSMP=n ends with arch/x86/kernel/built-in.o: In function `is_vsmp_box': (.text+0x1178d): undefined reference to `early_pci_allowed' arch/x86/kernel/built-in.o: In function `is_vsmp_box': (.text+0x117a9): undefined reference to `read_pci_config' arch/x86/kernel/built-in.o: In function `...

Hi, This series of five patches turns the vsmp architecture support in x86_64 into a paravirt client. If PARAVIRT is on, the probe function vsmp_init() is run unconditionally, patching the necessary irq functions accordingly if running ontop of such box.

Hi, This series of five patches turns the vsmp architecture support in x86_64 into a paravirt client. If PARAVIRT is on, the probe function vsmp_init() is run unconditionally, patching the necessary irq functions accordingly if running ontop of such box.

On Tue, 11 Mar 2008 01:14:34 -0700 Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc5/2.6.25-rc5-mm1/ randconfig (x86_64) with PCI=n PARAVIRT=y VSMP=n ends with arch/x86/kernel/built-in.o: In function `is_vsmp_box': (.text+0x1178d): undefined reference to `early_pci_allowed' arch/x86/kernel/built-in.o: In function `is_vsmp_box': (.text+0x117a9): undefined reference to `read_pci_config' arch/x86/kernel/built-in.o: In function `...

I have a 10 blade cluster of just hardware - I can install what I want, how I want. ? What options are there if I wanted to build the 10 blades as one large beast, but _NOT_ necessarily for someone doing grid-type work? ? ?Some users don't now how to program that way, but they'd like to have their program run on something that acts like a single processor, but a massive single processor

Josh Poimboeuf <jpoimboe at redhat.com> writes: > - For the most common runtime cases (everything except Xen and vSMP), > vmlinux disassembly now matches what the actual runtime code looks > like. This improves debuggability and kernel developer sanity (a > precious resource). > > ... > > - It's hopefully a first step in simplifying paravirt patching by > getting rid of .parain...

Hi folks, Here is the result of the latest work on the pvops front, after the x86 arch merge. From the functionality point of view, almost nothing was changed, except for proper vsmp support - which was discussed, but not implemented before - and the introduction of smp_ops in x86_64, which eased the merging of the smp header. Speaking of the merge, a significant part (although not majority) of this work is merging things that was not possible before, due to the lack of paravi...

Hi folks, Here is the result of the latest work on the pvops front, after the x86 arch merge. From the functionality point of view, almost nothing was changed, except for proper vsmp support - which was discussed, but not implemented before - and the introduction of smp_ops in x86_64, which eased the merging of the smp header. Speaking of the merge, a significant part (although not majority) of this work is merging things that was not possible before, due to the lack of paravi...

...ing an indirect call with a direct call). That's a bit more complex, but overall this approach should cause less confusion than before because the vmlinux code is now much more likely to represent the actual runtime state of the code in the most common paravirt cases (everything except Xen and vSMP). It could be simplified by redesigning the paravirt patching code such that it uses alternatives for all of its patching. Instead of using pv ops to specify which functions they need, they would instead set CPU feature bits, which would then be used by the alternatives to decide what to replace...

...(pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases (everything except Xen and vSMP), vmlinux disassembly now matches what the actual runtime code looks like. This improves debuggability and kernel developer sanity (a precious resource). - It fixes a KASAN warning in the ORC unwinder due to objtool not understanding the .parainstructions stuff. - It's hopefully a fi...

...(pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases (everything except Xen and vSMP), vmlinux disassembly now matches what the actual runtime code looks like. This improves debuggability and kernel developer sanity (a precious resource). - It fixes a KASAN warning in the ORC unwinder due to objtool not understanding the .parainstructions stuff. - It's hopefully a fi...

...| 4 +- arch/x86/kernel/kvm.c | 18 ++- arch/x86/kernel/kvmclock.c | 4 +- arch/x86/kernel/paravirt-spinlocks.c | 15 +- arch/x86/kernel/paravirt.c | 278 +++++++++++++++++----------------- arch/x86/kernel/tsc.c | 2 +- arch/x86/kernel/vsmp_64.c | 11 +- arch/x86/xen/enlighten_pv.c | 32 ++-- arch/x86/xen/irq.c | 2 +- arch/x86/xen/mmu_hvm.c | 2 +- arch/x86/xen/mmu_pv.c | 28 ++-- arch/x86/xen/spinlock.c | 12 +- arch/x86/xen/time.c...

Hi folks, After some time away from it, and a big rebase as a consequence, here is the updated version of paravirt_ops for x86_64, heading to inclusion. Your criticism is of course, very welcome. Have fun -- arch/x86_64/Kconfig | 11 arch/x86_64/ia32/syscall32.c | 2 arch/x86_64/kernel/Makefile | 1 arch/x86_64/kernel/apic.c | 2

Hi folks, After some time away from it, and a big rebase as a consequence, here is the updated version of paravirt_ops for x86_64, heading to inclusion. Your criticism is of course, very welcome. Have fun -- arch/x86_64/Kconfig | 11 arch/x86_64/ia32/syscall32.c | 2 arch/x86_64/kernel/Makefile | 1 arch/x86_64/kernel/apic.c | 2

...include/asm/tlbflush.h | 4 +- arch/x86/kernel/head_64.S | 2 +- arch/x86/kernel/kvm.c | 22 ++++++--- arch/x86/kernel/paravirt.c | 37 +++++++++++-- arch/x86/kernel/tsc.c | 2 +- arch/x86/kernel/vsmp_64.c | 2 +- arch/x86/xen/Kconfig | 2 +- 26 files changed, 219 insertions(+), 50 deletions(-)

...include/asm/tlbflush.h | 4 +- arch/x86/kernel/head_64.S | 2 +- arch/x86/kernel/kvm.c | 22 ++++++--- arch/x86/kernel/paravirt.c | 37 +++++++++++-- arch/x86/kernel/tsc.c | 2 +- arch/x86/kernel/vsmp_64.c | 2 +- arch/x86/xen/Kconfig | 2 +- 26 files changed, 219 insertions(+), 50 deletions(-)

...nel/paravirt-spinlocks.c | 15 +- arch/x86/kernel/paravirt.c | 290 ++++++++++++++-------------- arch/x86/kernel/paravirt_patch_32.c | 9 +- arch/x86/kernel/paravirt_patch_64.c | 11 +- arch/x86/kernel/tsc.c | 2 +- arch/x86/kernel/vsmp_64.c | 17 +- arch/x86/xen/Kconfig | 1 + arch/x86/xen/enlighten_pv.c | 32 +-- arch/x86/xen/irq.c | 2 +- arch/x86/xen/mmu_hvm.c | 2 +- arch/x86/xen/mmu_pv.c | 28...

...kernel/paravirt-spinlocks.c | 15 +- arch/x86/kernel/paravirt.c | 292 ++++++++++---------- arch/x86/kernel/paravirt_patch_32.c | 57 ++-- arch/x86/kernel/paravirt_patch_64.c | 65 ++--- arch/x86/kernel/tsc.c | 2 +- arch/x86/kernel/vsmp_64.c | 24 +- arch/x86/xen/Kconfig | 1 + arch/x86/xen/enlighten_pv.c | 31 ++- arch/x86/xen/irq.c | 2 +- arch/x86/xen/mmu_hvm.c | 2 +- arch/x86/xen/mmu_pv.c | 28...

...x86/kernel/paravirt.c | 303 +----------- arch/x86/kernel/paravirt_full.c | 277 +++++++++++ arch/x86/kernel/paravirt_patch_32.c | 36 +- arch/x86/kernel/paravirt_patch_64.c | 50 +- arch/x86/kernel/tsc.c | 2 +- arch/x86/kernel/vsmp_64.c | 18 +- arch/x86/lguest/Kconfig | 1 + arch/x86/lguest/boot.c | 100 ++-- arch/x86/xen/Kconfig | 1 + arch/x86/xen/Makefile | 8 +- arch/x86/xen/enlighten_hvm.c | 4...