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
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
> > 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.
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 {
> 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 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
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Node ID 9a758f814f60166dcf4a386bb9835f58c8f68502
# Parent dbc74db14a4b39d359365fcf8257216d968fa269
# Parent 6af601c5ebe192a0de72430cdd94da5ba46ff287
[POWERPC] merge
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
---
xen/arch
# 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:
On Fri, 2006-12-15 at 20:00 +, Keir Fraser wrote:
>
> > Also, that doesn't solve the lazy register saving problem.
>
> I assume this is a PPC-specific issue?
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 ma
On 15/12/06 19:09, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
> Ah OK, I see now how x86 is doing that. I don't think that code flow
> really makes sense: why would you jump out of do_softirq() into assembly
> just to call do_softirq() again?
Well, that's the way it works out on x86. It is a b
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 Technol
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 reprogramm
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 ff
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 sche
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(), w
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 usi
# 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 regar
18 matches
Mail list logo