Displaying 20 results from an estimated 900 matches similar to: "[RFC/PATCH PV_OPS X86_64 04/17] pavarvirt_ops - apci header updates"
2007 Apr 18
0
[RFC, PATCH 15/24] i386 Vmi apic header
Move APIC read / write accessors to sub-arch layer. Note that we
don't bother to implement apic_write_atomic any different, as it
is only present to work around old processor erratums (Pentium
Processor Spec update 11AP), and VMI kernels do not offer support
for this class of processor.
Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Daniel Arai <arai@vmware.com>
2007 Apr 18
0
[RFC, PATCH 15/24] i386 Vmi apic header
Move APIC read / write accessors to sub-arch layer. Note that we
don't bother to implement apic_write_atomic any different, as it
is only present to work around old processor erratums (Pentium
Processor Spec update 11AP), and VMI kernels do not offer support
for this class of processor.
Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Daniel Arai <arai@vmware.com>
2007 Apr 18
2
[PATCH] x86_64 paravirt_ops port
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
2007 Apr 18
2
[PATCH] x86_64 paravirt_ops port
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
2007 Apr 18
0
[PATCH 6/6] VMI timer patches
VMI timer code. It works by taking over the local APIC clock when APIC is
configured, which requires a couple hooks into the APIC code. The backend
timer code could be commonized into the timer infrastructure, but there are
some pieces missing (stolen time, in particular), and the exact semantics
of when to do accounting for NO_IDLE need to be shared between different
hypervisors as well. So
2007 Apr 18
0
[PATCH 6/6] VMI timer patches
VMI timer code. It works by taking over the local APIC clock when APIC is
configured, which requires a couple hooks into the APIC code. The backend
timer code could be commonized into the timer infrastructure, but there are
some pieces missing (stolen time, in particular), and the exact semantics
of when to do accounting for NO_IDLE need to be shared between different
hypervisors as well. So
2007 Apr 18
0
[PATCH 5/5] Vmi timer.patch
VMI timer code. It works by taking over the local APIC clock when APIC is
configured, which requires a couple hooks into the APIC code. The backend
timer code could be commonized into the timer infrastructure, but there are
some pieces missing (stolen time, in particular), and the exact semantics
of when to do accounting for NO_IDLE need to be shared between different
hypervisors as well. So
2007 Apr 18
0
[PATCH 5/5] Vmi timer.patch
VMI timer code. It works by taking over the local APIC clock when APIC is
configured, which requires a couple hooks into the APIC code. The backend
timer code could be commonized into the timer infrastructure, but there are
some pieces missing (stolen time, in particular), and the exact semantics
of when to do accounting for NO_IDLE need to be shared between different
hypervisors as well. So
2012 Apr 20
1
[PATCH v2 0/2] fix "perf top" soft lockups under Xen
v2:
- fix compile issues if no CONFIG_SMP, Konrad Rzeszutek Wilk
- move inc_irq_stat after irq_work_run
These 2 patches fixed the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506
Both Steven and I tested it and "perf top" works well now.
The soft lockup code path is:
__irq_work_queue
arch_irq_work_raise
2007 Apr 18
2
refactoring io_apic.c
OK, I need to do something like this to io_apic.c - split the hardware
specific parts out under mach-default, so we can override them for other
subarchitectures. It's not finished, needs header file and makefile
work. Would you be willing to take this if I do it? I'm not going to
bother if you're not, such refactorings are a pig to maintain out of
tree.
Frankly, io_apic.c needs a
2007 Apr 18
2
refactoring io_apic.c
OK, I need to do something like this to io_apic.c - split the hardware
specific parts out under mach-default, so we can override them for other
subarchitectures. It's not finished, needs header file and makefile
work. Would you be willing to take this if I do it? I'm not going to
bother if you're not, such refactorings are a pig to maintain out of
tree.
Frankly, io_apic.c needs a
2012 Apr 15
0
(no subject)
Hi all,
These 2 patches try to fix the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506
I tested it with 3.4-rc2 and "perf top" works well now.
Steven,
Could you please help to test it too?
The soft lockup code path is:
__irq_work_queue
arch_irq_work_raise
apic->send_IPI_self(IRQ_WORK_VECTOR);
apic_send_IPI_self
2012 Apr 15
0
Re: [PATCH 0/2] fix "perf top" soft lockups under Xen
(Forgot mail subject, add it)
On Sun, Apr 15, 2012 at 2:09 PM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> Hi all,
>
> These 2 patches try to fix the "perf top" soft lockups under Xen
> reported by Steven at: https://lkml.org/lkml/2012/2/9/506
>
> I tested it with 3.4-rc2 and "perf top" works well now.
>
> Steven,
> Could you please help to test it
2007 Apr 18
0
[RFC/PATCH PV_OPS X86_64 01/17] paravirt_ops - core changes
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 @@
+/*
2007 Apr 18
0
[RFC/PATCH PV_OPS X86_64 01/17] paravirt_ops - core changes
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 @@
+/*
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
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
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