# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 20bd3b7b7519e01f7b6bfa97c7a655e1dc027f5d
# Parent 887e1cbac6154da0a3a3c2433fbc5b0fc2a1c9b8
[XEN][POWERPC] Normalize timbase_freq to a 64bit value
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
---
xen/arch/powerpc/boot_of.c
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 6af601c5ebe192a0de72430cdd94da5ba46ff287
# Parent 20bd3b7b7519e01f7b6bfa97c7a655e1dc027f5d
[XEN][POWERPC] workaround for context_switch() bug
We have a bug in that if we switch domains in schedule() we switch
right away
Using dcbz avoids first reading a cache line from memory before writing to the
line.
Timing results (starting with clean cache, ie no write-backs for dirty lines):
JS20:
elapsed time: 0x9f5e
elapsed time using dcbz: 0x569e
elapsed time: 0x9fe9
elapsed time
PowerPC's timer interrupt (called the decrementer) is a one-shot timer,
not periodic. When it goes off, entering the hypervisor, we first set it
very high so it won't interrupt hypervisor code, then
raise_softirq(TIMER_SOFTIRQ). We know that timer_softirq_action() will
then call reprogam_timer(),
On 15/12/06 17:27, Hollis Blanchard [EMAIL PROTECTED] wrote:
We recently uncovered a bug on PowerPC where if a timer tick arrives
just inside schedule() while interrupts are still enabled, the
decrementer is never reprogrammed to that appropriate value. This is
because once inside schedule(),
Just saw this on a JS21 blade (internal name is cso52):
(XEN) MACHINE CHECK: IS Recoverable
(XEN) [ Xen-3.0-unstable ]
(XEN) CPU: DOMID:
(XEN) pc 10046510 msr 000cf032
(XEN) lr 10063bf4 ctr 0fde93c0
(XEN) srr0 srr1
On Fri, 2006-12-15 at 17:36 +, Keir Fraser wrote:
On 15/12/06 17:27, Hollis Blanchard [EMAIL PROTECTED] wrote:
We recently uncovered a bug on PowerPC where if a timer tick arrives
just inside schedule() while interrupts are still enabled, the
decrementer is never reprogrammed to that
On Fri, 2006-12-15 at 11:50 -0500, poff wrote:
Using dcbz avoids first reading a cache line from memory before
writing to the line.
Timing results (starting with clean cache, ie no write-backs for dirty
lines):
So do you have a patch for copy_page()?
--
Hollis Blanchard
IBM Linux Technology
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Node ID dbc74db14a4b39d359365fcf8257216d968fa269
# Parent 887e1cbac6154da0a3a3c2433fbc5b0fc2a1c9b8
[POWERPC][XEN] Add support for || as a xen/dom0 commandline divider.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
Signed-off-by:
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Node ID 9a758f814f60166dcf4a386bb9835f58c8f68502
# Parent dbc74db14a4b39d359365fcf8257216d968fa269
# Parent 6af601c5ebe192a0de72430cdd94da5ba46ff287
[POWERPC] merge
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
On 15/12/06 20:41, Hollis Blanchard [EMAIL PROTECTED] wrote:
It's an issue with any architecture with a large number of registers
which aren't automatically saved by hardware (and a C ABI that makes
some of them non-volatile).
x86 has a small number of registers. ia64 automatically saves
So do you have a patch for copy_page()?
In Xen for PPC, the only copy_page() is in arch/powerpc/mm.c:
extern void copy_page(void *dp, void *sp)
{
if (on_systemsim()) {
systemsim_memcpy(dp, sp, PAGE_SIZE);
} else {
memcpy(dp, sp, PAGE_SIZE);
}
}
1) Also copy_page is
On Fri, 2006-12-15 at 16:40 -0500, poff wrote:
So do you have a patch for copy_page()?
In Xen for PPC, the only copy_page() is in arch/powerpc/mm.c:
extern void copy_page(void *dp, void *sp)
{
if (on_systemsim()) {
systemsim_memcpy(dp, sp, PAGE_SIZE);
} else {
3) Useful when PPC must do page copies in place of 'page flipping'.
So you're saying we should worry about it later?
For the future, copy_page using dcbz:
diff -r 7669fca80bfc xen/arch/powerpc/mm.c
--- a/xen/arch/powerpc/mm.c Mon Dec 04 11:46:53 2006 -0500
+++ b/xen/arch/powerpc/mm.c
On Fri, 2006-12-15 at 17:50 -0500, poff wrote:
3) Useful when PPC must do page copies in place of 'page flipping'.
So you're saying we should worry about it later?
For the future, copy_page using dcbz:
diff -r 7669fca80bfc xen/arch/powerpc/mm.c
--- a/xen/arch/powerpc/mm.c Mon Dec
On Fri, 2006-12-15 at 21:39 +, Keir Fraser wrote:
On 15/12/06 20:41, Hollis Blanchard [EMAIL PROTECTED] wrote:
It's an issue with any architecture with a large number of registers
which aren't automatically saved by hardware (and a C ABI that makes
some of them non-volatile).
x86
16 matches
Mail list logo
