similar to: [PATCH] remove overwrite_paravirt_ops

plain text document attachment (xx-paravirt-core.patch) Paravirt Ops core files. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/paravirt.c =================================================================== --- /dev/null +++ clean-start/arch/x86_64/kernel/paravirt.c @@ -0,0 +1,504 @@ +/*

plain text document attachment (xx-paravirt-core.patch) Paravirt Ops core files. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/paravirt.c =================================================================== --- /dev/null +++ clean-start/arch/x86_64/kernel/paravirt.c @@ -0,0 +1,504 @@ +/*

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

Hi all, I've been working on a port of paravirt_ops for the x86_64 architectures for a couple of days. Here's the result so far. I'm posting it soon for early cooments. The more, the better. It's obviously based on the previous work for i386, with the needed modifications. By now, I'm able to boot a bare metal kernel, but there are still some known issues, that are in my TODO

Hi all, I've been working on a port of paravirt_ops for the x86_64 architectures for a couple of days. Here's the result so far. I'm posting it soon for early cooments. The more, the better. It's obviously based on the previous work for i386, with the needed modifications. By now, I'm able to boot a bare metal kernel, but there are still some known issues, that are in my TODO

Fix paravirt_probe() macro so that handing it start_kernel doesn't evoke a warning (start_kernel is asmlinkage). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/dontdiff --minimal linux-2.6.19-rc4-mm2/include/asm-i386/paravirt.h working-2.6.19-rc4-mm2-warnings/include/asm-i386/paravirt.h ---

Fix paravirt_probe() macro so that handing it start_kernel doesn't evoke a warning (start_kernel is asmlinkage). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/dontdiff --minimal linux-2.6.19-rc4-mm2/include/asm-i386/paravirt.h working-2.6.19-rc4-mm2-warnings/include/asm-i386/paravirt.h ---

The current code simply calls "start_kernel" directly if we're under a hypervisor and no paravirt_ops backend wants us, because paravirt.c registers that as a backend. This was always a vain hope; start_kernel won't get far without setup. It's also impossible for paravirt_ops backends which don't sit in the arch/i386/kernel directory: they can't link before

The current code simply calls "start_kernel" directly if we're under a hypervisor and no paravirt_ops backend wants us, because paravirt.c registers that as a backend. This was always a vain hope; start_kernel won't get far without setup. It's also impossible for paravirt_ops backends which don't sit in the arch/i386/kernel directory: they can't link before

In a virtual environment, device drivers such as legacy IDE will waste quite a lot of time probing for their devices which will never appear. This helper function allows a paravirt implementation to lay claim to the whole iomem and ioport space, thereby disabling all device drivers trying to claim IO resources. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Rusty Russell

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,

[ 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

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

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,

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++