search for: xen_mc_callback

...ackport for 2.6.24-3.2.y arch/x86/xen/multicalls.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c index 0d82003..5270407 100644 --- a/arch/x86/xen/multicalls.c +++ b/arch/x86/xen/multicalls.c @@ -195,9 +195,10 @@ void xen_mc_callback(void (*fn)(void *), void *data) struct mc_buffer *b = &__get_cpu_var(mc_buffer); struct callback *cb; - if (b->cbidx == MC_BATCH) { + if (b->cbidx >= MC_BATCH) { trace_xen_mc_flush_reason(XEN_MC_FL_CALLBACK); xen_mc_flush(); + return; } trace_xen_mc_callback(fn, data...

...ackport for 2.6.24-3.2.y arch/x86/xen/multicalls.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c index 0d82003..5270407 100644 --- a/arch/x86/xen/multicalls.c +++ b/arch/x86/xen/multicalls.c @@ -195,9 +195,10 @@ void xen_mc_callback(void (*fn)(void *), void *data) struct mc_buffer *b = &__get_cpu_var(mc_buffer); struct callback *cb; - if (b->cbidx == MC_BATCH) { + if (b->cbidx >= MC_BATCH) { trace_xen_mc_flush_reason(XEN_MC_FL_CALLBACK); xen_mc_flush(); + return; } trace_xen_mc_callback(fn, data...

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

...= pfn_to_mfn(PFN_DOWN(cr3)); - - op = mcs.args; - op->cmd = MMUEXT_NEW_BASEPTR; - op->arg1.mfn = mfn; + MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF); - MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF); + /* Update xen_update_cr3 once the batch has actually + been submitted. */ + xen_mc_callback(set_current_cr3, (void *)cr3); - xen_mc_issue(PARAVIRT_LAZY_CPU); - } + xen_mc_issue(PARAVIRT_LAZY_CPU); /* interrupts restored */ } /* Early in boot, while setting up the initial pagetable, assume @@ -1113,6 +1133,7 @@ asmlinkage void __init xen_start_kernel( /* keep using Xen gdt for no...

...= pfn_to_mfn(PFN_DOWN(cr3)); - - op = mcs.args; - op->cmd = MMUEXT_NEW_BASEPTR; - op->arg1.mfn = mfn; + MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF); - MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF); + /* Update xen_update_cr3 once the batch has actually + been submitted. */ + xen_mc_callback(set_current_cr3, (void *)cr3); - xen_mc_issue(PARAVIRT_LAZY_CPU); - } + xen_mc_issue(PARAVIRT_LAZY_CPU); /* interrupts restored */ } /* Early in boot, while setting up the initial pagetable, assume @@ -1113,6 +1133,7 @@ asmlinkage void __init xen_start_kernel( /* keep using Xen gdt for no...

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),