Displaying 20 results from an estimated 400 matches similar to: "[PATCH] make setup_secondary_clock definition dependent on local apic"
2008 Mar 18
3
[PATCH 0/3 - resend] kvmclock reboot
Avi,
Hope this series is okay now.
Thanks for the testing
2007 Sep 28
2
[PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops
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
2007 Sep 28
2
[PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops
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
2007 Oct 09
2
[PATCH RFC REPOST 1/2] paravirt: refactor struct paravirt_ops into smaller pv_*_ops
[ 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
2007 Oct 09
2
[PATCH RFC REPOST 1/2] paravirt: refactor struct paravirt_ops into smaller pv_*_ops
[ 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
2015 Nov 17
1
[PATCH] paravirt: remove unused pv_apic_ops structure
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
2015 Nov 17
1
[PATCH] paravirt: remove unused pv_apic_ops structure
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
2007 Jul 09
1
[PATCH RFC] first cut at splitting up paravirt_ops
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,
2007 Jul 09
1
[PATCH RFC] first cut at splitting up paravirt_ops
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,
2007 Oct 09
0
[PATCH RFC REPOST 2/2] paravirt: clean up lazy mode handling
[ 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? ]
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This
2007 Oct 09
0
[PATCH RFC REPOST 2/2] paravirt: clean up lazy mode handling
[ 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? ]
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This
2008 Jul 15
4
Patch from LKML
> On Tue, Jul 15, 2008 at 10:33 AM, Suresh Siddha
> <suresh.b.siddha at intel.com> wrote:
> > On Sun, Jul 13, 2008 at 10:19:35PM -0700, Yinghai Lu wrote:
> >>
> >> fix for pv.
> >>
> >> Signed-off-by: Yinghai Lu <yhlu.kernel at gmail.com>
> >>
> >> ---
> >> arch/x86/kernel/paravirt.c | 5 ----
> >>
2008 Jul 15
4
Patch from LKML
> On Tue, Jul 15, 2008 at 10:33 AM, Suresh Siddha
> <suresh.b.siddha at intel.com> wrote:
> > On Sun, Jul 13, 2008 at 10:19:35PM -0700, Yinghai Lu wrote:
> >>
> >> fix for pv.
> >>
> >> Signed-off-by: Yinghai Lu <yhlu.kernel at gmail.com>
> >>
> >> ---
> >> arch/x86/kernel/paravirt.c | 5 ----
> >>
2007 Oct 01
2
[PATCH RFC] paravirt: cleanup lazy mode handling
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This complicates each paravirt backend, since it needs to deal with
all the possible state transitions, handling flushing, etc. In
particular, flushing is quite distinct from the other 4 functions,
2007 Oct 01
2
[PATCH RFC] paravirt: cleanup lazy mode handling
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This complicates each paravirt backend, since it needs to deal with
all the possible state transitions, handling flushing, etc. In
particular, flushing is quite distinct from the other 4 functions,
2008 Apr 16
1
[PATCH] kvm: move kvmclock initialization inside kvm_guest_init
It makes no sense for the clock initialization to be
hanging around in setup_32.c when we have a generic kvm guest
initialization function available. So, we move kvmclock_init()
inside such a function, leading to a cleaner code.
Signed-off-by: Glauber Costa <gcosta at redhat.com>
---
arch/x86/kernel/kvm.c | 2 ++
arch/x86/kernel/setup_32.c | 4 ----
include/linux/kvm_para.h |
2008 Apr 16
1
[PATCH] kvm: move kvmclock initialization inside kvm_guest_init
It makes no sense for the clock initialization to be
hanging around in setup_32.c when we have a generic kvm guest
initialization function available. So, we move kvmclock_init()
inside such a function, leading to a cleaner code.
Signed-off-by: Glauber Costa <gcosta at redhat.com>
---
arch/x86/kernel/kvm.c | 2 ++
arch/x86/kernel/setup_32.c | 4 ----
include/linux/kvm_para.h |
2013 Nov 20
0
[PATCH -tip v3 02/23] kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist
Introduce NOKPROBE_SYMBOL() macro which builds a kprobe
blacklist in build time. The usage of this macro is similar
to the EXPORT_SYMBOL, put the NOKPROBE_SYMBOL(function); just
after the function definition.
If CONFIG_KPROBES=y, the macro is expanded to the definition
of a static data structure of kprobe_blackpoint which is
initialized for the function and put the address of the data
structure
2018 Aug 10
0
[PATCH 04/10] x86/paravirt: use a single ops structure
Instead of using six globally visible paravirt ops structures combine
them in a single structure, keeping the original structures as
sub-structures.
This avoids the need to assemble struct paravirt_patch_template at
runtime on the stack each time apply_paravirt() is being called (i.e.
when loading a module).
Signed-off-by: Juergen Gross <jgross at suse.com>
---
arch/x86/hyperv/mmu.c
2008 May 08
4
[PATCH 0/4] paravirt clock series.
Respin of the paravirt clock patch series.
On the host side the kvm paravirt clock is made compatible with the
xen clock.
On the guest side some xen code has been factored out into a separate
source file shared by both kvm and xen clock implementations.
This time it should work ok for kvm smp guests ;)
cheers,
Gerd