xen/paravirt_ops patches for 2.6.24
Subsystems (10)
cover xen/paravirt_ops patches for 2.6.24
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
- yield if the target vcpu of an IPI is not currently running
- add post-batch callbacks for multicalls [*]
- deal with unpinning pagetables when another vcpu still [*] has a cr3 reference
- deal with split ptelocks by pinning each pte page separately under lock
- determine the kernel/hypervisor address split dynamically
- use the right arg structure for register_vcpu_info [*]
- add extra debugging output for failed multicalls
XFS:
- eagerly unmap vmapped areas to avoid confict with Xen
[*] bugfix needed for 2.6.23. I've also cc:d them to [email protected]
Diffstat:
arch/x86/kernel/alternative.c | 4 arch/x86/kernel/asm-offsets_32.c | 14 arch/x86/kernel/entry_32.S | 2 arch/x86/kernel/paravirt_32.c | 234 ++++++++----- arch/x86/kernel/vmi_32.c | 211 ++++++------ arch/x86/mm/init_32.c | 22 - arch/x86/xen/enlighten.c | 295 +++++++++------- arch/x86/xen/mmu.c | 149 ++++++-- arch/x86/xen/multicalls.c | 52 ++ arch/x86/xen/multicalls.h | 5 arch/x86/xen/smp.c | 14 arch/x86/xen/time.c | 6 arch/x86/xen/xen-ops.h | 10 drivers/char/hvc_lguest.c | 2 drivers/lguest/core.c | 6 drivers/lguest/lguest.c | 154 ++++---- drivers/lguest/lguest_bus.c | 2 fs/xfs/linux-2.6/xfs_buf.c | 13 include/asm-x86/paravirt.h | 507 ++++++++++++++++------------- include/asm-x86/pgtable-3level-defs.h | 2 include/xen/interface/vcpu.h | 5 mm/Kconfig | 1 22 files changed, 1027 insertions(+), 683 deletions(-)
Thanks,
J
PATCH 1/12 paravirt: 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 functionspv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for managing interrupt state pv_apic_ops - APIC operationspv_mmu_ops - operations for managing pagetables
There are several motivations for this:
1. Some of these ops will be general to all x86, and some will be i386/x86-64 specific. This makes it easier to share common stuff while allowing separate implementations where needed.
2. At the moment we must export all of paravirt_ops, but modules only need selected parts of it. This allows us to export on a case by case basis (and also choose which export license we want to apply).
3. Functional groupings make things a bit more readable.
Struct paravirt_ops is now only used as a template to generate patch-site identifiers, and to extract function pointers for inserting into jmp/calls when patching. It is only instantiated when needed.
--- arch/x86/kernel/alternative.c | 4 arch/x86/kernel/asm-offsets_32.c | 14 arch/x86/kernel/entry_32.S | 2 arch/x86/kernel/paravirt_32.c | 182 +++++++----- arch/x86/kernel/vmi_32.c | 168 +++++------ arch/x86/xen/enlighten.c | 152 ++++++---- drivers/char/hvc_lguest.c | 2 drivers/lguest/core.c | 6 drivers/lguest/lguest.c | 124 ++++---- drivers/lguest/lguest_bus.c | 2 include/asm-x86/paravirt.h | 477 ++++++++++++++++++--------------- include/asm-x86/pgtable-3level-defs.h | 2 12 files changed, 630 insertions(+), 505 deletions(-)
===================================================================
arch/x86/kernel/alternative.c +2 -2
@@ -369,8 +369,8 @@ void apply_paravirt(struct paravirt_patcBUG_ON (p->len >MAX_PATCH_LEN );/* prep the buffer with the original instructions */ memcpy (insnbuf, p->instr, p->len); - used = paravirt_ops.patch (p->instrtype, p->clobbers, insnbuf, - (unsigned long )p->instr, p->len); + used = pv_init_ops.patch (p->instrtype, p->clobbers, insnbuf, + (unsigned long )p->instr, p->len);BUG_ON (used > p->len);
===================================================================
arch/x86/kernel/asm-offsets_32.c +8 -6
@@ -116,12 +116,14 @@ void foo(void)#ifdef CONFIG_PARAVIRT BLANK (); -OFFSET (PARAVIRT_enabled, paravirt_ops, paravirt_enabled); -OFFSET (PARAVIRT_irq_disable, paravirt_ops, irq_disable); -OFFSET (PARAVIRT_irq_enable, paravirt_ops, irq_enable); -OFFSET (PARAVIRT_irq_enable_sysexit, paravirt_ops, irq_enable_sysexit); -OFFSET (PARAVIRT_iret, paravirt_ops, iret); -OFFSET (PARAVIRT_read_cr0, paravirt_ops, read_cr0); +OFFSET (PARAVIRT_enabled, pv_info, paravirt_enabled); +OFFSET (PARAVIRT_PATCH_pv_cpu_ops, paravirt_patch_template, pv_cpu_ops); +OFFSET (PARAVIRT_PATCH_pv_irq_ops, paravirt_patch_template, pv_irq_ops); +OFFSET (PV_IRQ_irq_disable, pv_irq_ops, irq_disable); +OFFSET (PV_IRQ_irq_enable, pv_irq_ops, irq_enable); +OFFSET (PV_CPU_iret, pv_cpu_ops, iret); +OFFSET (PV_CPU_irq_enable_sysexit, pv_cpu_ops, irq_enable_sysexit); +OFFSET (PV_CPU_read_cr0, pv_cpu_ops, read_cr0);#endif #ifdef CONFIG_XEN
===================================================================
arch/x86/kernel/entry_32.S +1 -1
@@ -434,7 +434,7 @@ ldt_ss: * is still available to implement the setting of the high * 16-bits in the INTERRUPT_RETURN paravirt-op. */ - cmpl $0, paravirt_ops+PARAVIRT_enabled + cmpl $0, pv_info+PARAVIRT_enabled jne restore_nocheck #endif
===================================================================
arch/x86/kernel/paravirt_32.c +107 -75
295 lines not on this page · raw message
===================================================================
arch/x86/kernel/vmi_32.c +84 -84
267 lines not on this page · raw message
===================================================================
arch/x86/xen/enlighten.c +88 -64
255 lines not on this page · raw message
===================================================================
drivers/char/hvc_lguest.c +1 -1
@@ -115,7 +115,7 @@ static struct hv_ops lguest_cons = {* (0), and the struct hv_ops containing the put_chars() function. */ static int __init cons_init (void ) { -if (strcmp (paravirt_ops.name,"lguest" ) !=0 ) +if (strcmp (pv_info.name,"lguest" ) !=0 )return 0 ;return hvc_instantiate (0 ,0 , &lguest_cons);
===================================================================
drivers/lguest/core.c +3 -3
@@ -248,8 +248,8 @@ static void unmap_switcher(void) }/*H:130 Our Guest is usually so well behaved; it never tries to do things it -* isn't allowed to. Unfortunately, "struct paravirt_ops" isn't quite -* complete, because it doesn't contain replacements for the Intel I/O +* isn't allowed to. Unfortunately, Linux's paravirtual infrastructure isn't +* quite complete, because it doesn't contain replacements for the Intel I/O * instructions. As a result, the Guest sometimes fumbles across one during * the boot process as it probes for various things which are usually attached * to a PC.
@@ -694,7 +694,7 @@ static int __init init(void)/* Lguest can't run under Xen, VMI or itself. It does Tricky Stuff. */ if (paravirt_enabled ()) { -printk ("lguest is afraid of %s\n" , paravirt_ops.name); +printk ("lguest is afraid of %s\n" , pv_info.name);return -EPERM ; }
===================================================================
drivers/lguest/lguest.c +69 -55
177 lines not on this page · raw message
===================================================================
drivers/lguest/lguest_bus.c +1 -1
@@ -201,7 +201,7 @@ static void scan_devices(void)* "struct lguest_device_desc" array. */ static int __init lguest_bus_init (void ) { -if (strcmp (paravirt_ops.name,"lguest" ) !=0 ) +if (strcmp (pv_info.name,"lguest" ) !=0 )return 0 ;/* Devices are in a single page above top of "normal" mem */
===================================================================
include/asm-x86/paravirt.h +265 -212
1,015 lines not on this page · raw message
===================================================================
include/asm-x86/pgtable-3level-defs.h +1 -1
@@ -2,7 +2,7 @@#define _I386_PGTABLE_3LEVEL_DEFS_H#ifdef CONFIG_PARAVIRT -#define SHARED_KERNEL_PMD (paravirt_ops.shared_kernel_pmd) +#define SHARED_KERNEL_PMD (pv_info.shared_kernel_pmd)#else #define SHARED_KERNEL_PMD 1#endif
PATCH 2/12 paravirt: clean up lazy mode handling
In reply to Jeremy FitzhardingeCurrently, 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, and seems to just cause complication.
This patch removes the set_lazy_mode operation, and adds "enter" and "leave" lazy mode operations on mmu_ops and cpu_ops. All the logic associated with enter and leaving lazy states is now in common code (basically BUG_ONs to make sure that no mode is current when entering a lazy mode, and make sure that the mode is current when leaving). Also, flush is handled in a common way, by simply leaving and re-entering the lazy mode.
The result is that the Xen, lguest and VMI lazy mode implementations are much simpler.
--- arch/x86/kernel/paravirt_32.c | 58 +++++++++++++++++++++++++++++++++++++---- arch/x86/kernel/vmi_32.c | 45 ++++++++++++++++++------------- arch/x86/xen/enlighten.c | 44 +++++++++---------------------- arch/x86/xen/mmu.c | 2 - arch/x86/xen/multicalls.h | 2 - arch/x86/xen/xen-ops.h | 7 ---- drivers/lguest/lguest.c | 34 ++++++++---------------- include/asm-x86/paravirt.h | 52 +++++++++++++++++++++++------------- 8 files changed, 140 insertions(+), 104 deletions(-)
===================================================================
arch/x86/kernel/paravirt_32.c +53 -5
@@ -164,7 +164,6 @@ static void *get_call_destination(u8 typ {struct paravirt_patch_template tmpl = { .pv_init_ops = pv_init_ops, - .pv_misc_ops = pv_misc_ops, .pv_time_ops = pv_time_ops, .pv_cpu_ops = pv_cpu_ops, .pv_irq_ops = pv_irq_ops,
@@ -280,6 +279,49 @@ int paravirt_disable_iospace(void) }return ret; +} + +static DEFINE_PER_CPU(enum paravirt_lazy_mode, paravirt_lazy_mode) = PARAVIRT_LAZY_NONE; + +static inline void enter_lazy (enum paravirt_lazy_mode mode) +{ +BUG_ON (x86_read_percpu (paravirt_lazy_mode) !=PARAVIRT_LAZY_NONE ); +BUG_ON (preemptible ()); + +x86_write_percpu (paravirt_lazy_mode, mode); +} + +void paravirt_leave_lazy (enum paravirt_lazy_mode mode) +{ +BUG_ON (x86_read_percpu (paravirt_lazy_mode) != mode); +BUG_ON (preemptible ()); + +x86_write_percpu (paravirt_lazy_mode,PARAVIRT_LAZY_NONE ); +} + +void paravirt_enter_lazy_mmu (void ) +{ +enter_lazy (PARAVIRT_LAZY_MMU ); +} + +void paravirt_leave_lazy_mmu (void ) +{ +paravirt_leave_lazy (PARAVIRT_LAZY_MMU ); +} + +void paravirt_enter_lazy_cpu (void ) +{ +enter_lazy (PARAVIRT_LAZY_CPU ); +} + +void paravirt_leave_lazy_cpu (void ) +{ +paravirt_leave_lazy (PARAVIRT_LAZY_CPU ); +} + +enum paravirt_lazy_mode paravirt_get_lazy_mode (void ) +{ +return x86_read_percpu (paravirt_lazy_mode); }struct pv_info pv_info = {
@@ -347,6 +389,11 @@ struct pv_cpu_ops pv_cpu_ops = { .set_iopl_mask = native_set_iopl_mask, .io_delay = native_io_delay, + + .lazy_mode = { + .enter = paravirt_nop, + .leave = paravirt_nop, + }, };struct pv_apic_ops pv_apic_ops = {
@@ -360,10 +407,6 @@ struct pv_apic_ops pv_apic_ops = {#endif }; -struct pv_misc_ops pv_misc_ops = { - .set_lazy_mode = paravirt_nop, -}; -struct pv_mmu_ops pv_mmu_ops = { .pagetable_setup_start = native_pagetable_setup_start, .pagetable_setup_done = native_pagetable_setup_done,
@@ -414,6 +457,11 @@ struct pv_mmu_ops pv_mmu_ops = { .dup_mmap = paravirt_nop, .exit_mmap = paravirt_nop, .activate_mm = paravirt_nop, + + .lazy_mode = { + .enter = paravirt_nop, + .leave = paravirt_nop, + }, };EXPORT_SYMBOL_GPL (pv_time_ops);
===================================================================
arch/x86/kernel/vmi_32.c +26 -19
57 lines not on this page · raw message
===================================================================
arch/x86/xen/enlighten.c +14 -30
81 lines not on this page · raw message
===================================================================
arch/x86/xen/mmu.c +1 -1
@@ -154,7 +154,7 @@ void xen_set_pte_at(struct mm_struct *mm pte_t *ptep, pte_t pteval) {if (mm == current->mm || mm == &init_mm) { -if (xen_get_lazy_mode () ==PARAVIRT_LAZY_MMU ) { +if (paravirt_get_lazy_mode () ==PARAVIRT_LAZY_MMU ) {struct multicall_space mcs; mcs =xen_mc_entry (0 );
===================================================================
arch/x86/xen/multicalls.h +1 -1
@@ -35,7 +35,7 @@ void xen_mc_flush(void);/* Issue a multicall if we're not in a lazy mode */ static inline void xen_mc_issue (unsigned mode) { -if ((xen_get_lazy_mode () & mode) ==0 ) +if ((paravirt_get_lazy_mode () & mode) ==0 )xen_mc_flush ();/* restore flags saved in xen_mc_batch */
===================================================================
arch/x86/xen/xen-ops.h +0 -7
@@ -32,13 +32,6 @@ bool xen_vcpu_stolen(int vcpu);void xen_mark_init_mm_pinned (void ); -DECLARE_PER_CPU(enum paravirt_lazy_mode, xen_lazy_mode); - -static inline unsigned xen_get_lazy_mode (void ) -{ -return x86_read_percpu (xen_lazy_mode); -} -void __init xen_fill_possible_map (void );void __init xen_setup_vcpu_info_placement (void );
===================================================================
drivers/lguest/lguest.c +12 -22
@@ -97,29 +97,17 @@ static cycle_t clock_base;* them as a batch when lazy_mode is eventually turned off. Because hypercalls * are reasonably expensive, batching them up makes sense. For example, a * large mmap might update dozens of page table entries: that code calls -* lguest_lazy_mode(PARAVIRT_LAZY_MMU), does the dozen updates, then calls -* lguest_lazy_mode(PARAVIRT_LAZY_NONE). +* paravirt_enter_lazy_mmu(), does the dozen updates, then calls +* lguest_leave_lazy_mode(). * * So, when we're in lazy mode, we call async_hypercall() to store the call for * future processing. When lazy mode is turned off we issue a hypercall to * flush the stored calls. -* -* There's also a hack where "mode" is set to "PARAVIRT_LAZY_FLUSH" which -* indicates we're to flush any outstanding calls immediately. This is used -* when an interrupt handler does a kmap_atomic(): the page table changes must -* happen immediately even if we're in the middle of a batch. Usually we're -* not, though, so there's nothing to do. */ -static enum paravirt_lazy_mode lazy_mode;/* Note: not SMP-safe! */ -static void lguest_lazy_mode (enum paravirt_lazy_mode mode) -{ -if (mode ==PARAVIRT_LAZY_FLUSH ) { -if (unlikely (lazy_mode !=PARAVIRT_LAZY_NONE )) -hcall (LHCALL_FLUSH_ASYNC ,0 ,0 ,0 ); - }else { - lazy_mode = mode; -if (mode ==PARAVIRT_LAZY_NONE ) -hcall (LHCALL_FLUSH_ASYNC ,0 ,0 ,0 ); - } +*/ +static void lguest_leave_lazy_mode (void ) +{ +paravirt_leave_lazy (paravirt_get_lazy_mode ()); +hcall (LHCALL_FLUSH_ASYNC ,0 ,0 ,0 ); } static void lazy_hcall(unsigned long call,
@@ -127,7 +115,7 @@ static void lazy_hcall(unsigned long cal unsigned long arg2, unsigned long arg3) { - if (lazy_mode == PARAVIRT_LAZY_NONE) + if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) hcall(call, arg1, arg2, arg3); elseasync_hcall (call ,arg1 ,arg2 ,arg3 );
@@ -1011,6 +999,8 @@ __init void lguest_init(void *boot) pv_cpu_ops.write_gdt_entry = lguest_write_gdt_entry; pv_cpu_ops.write_idt_entry = lguest_write_idt_entry; pv_cpu_ops.wbinvd = lguest_wbinvd; + pv_cpu_ops.lazy_mode.enter = paravirt_enter_lazy_cpu; + pv_cpu_ops.lazy_mode.leave = lguest_leave_lazy_mode;/* pagetable management */ pv_mmu_ops.write_cr3 = lguest_write_cr3;
@@ -1022,6 +1012,8 @@ __init void lguest_init(void *boot) pv_mmu_ops.set_pmd = lguest_set_pmd; pv_mmu_ops.read_cr2 = lguest_read_cr2; pv_mmu_ops.read_cr3 = lguest_read_cr3; + pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu; + pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mode;#ifdef CONFIG_X86_LOCAL_APIC /* apic read/write intercepts */
@@ -1033,8 +1025,6 @@ __init void lguest_init(void *boot)/* time operations */ pv_time_ops.get_wallclock = lguest_get_wallclock; pv_time_ops.time_init = lguest_time_init; - - pv_misc_ops.set_lazy_mode = lguest_lazy_mode;/* Now is a good time to look at the implementations of these functions * before returning to the rest of lguest_init(). */
===================================================================
include/asm-x86/paravirt.h +33 -19
120 lines not on this page · raw message
PATCH 3/12 remove dead code in pgtable_cache_init
In reply to Jeremy FitzhardingeThe conversion from using a slab cache to quicklist left some residual dead code.
I note that in the conversion it now always allocates a whole page for the pgd, rather than the 32 bytes needed for a PAE pgd. Was this intended?
--- arch/x86/mm/init_32.c | 22 +++++----------------- 1 file changed, 5 insertions(+), 17 deletions(-)
===================================================================
arch/x86/mm/init_32.c +5 -17
@@ -746,24 +746,12 @@ struct kmem_cache *pmd_cache;void __init pgtable_cache_init (void ) { -size_t pgd_size =PTRS_PER_PGD *sizeof (pgd_t); - -if (PTRS_PER_PMD >1 ) { +if (PTRS_PER_PMD >1 ) pmd_cache =kmem_cache_create ("pmd" , -PTRS_PER_PMD *sizeof (pmd_t), -PTRS_PER_PMD *sizeof (pmd_t), -SLAB_PANIC , - pmd_ctor); -if (!SHARED_KERNEL_PMD ) { -/* If we're in PAE mode and have a non-shared -kernel pmd, then the pgd size must be a -page size. This is because the pgd_list -links through the page structure, so there -can only be one pgd per page for this to -work. */ - pgd_size =PAGE_SIZE ; - } - } +PTRS_PER_PMD *sizeof (pmd_t), +PTRS_PER_PMD *sizeof (pmd_t), +SLAB_PANIC , + pmd_ctor); }/*
PATCH 4/12 Clean up duplicate includes in arch/i386/xen/
In reply to Jeremy FitzhardingeThis patch cleans up duplicate includes in
arch/i386/xen/
--- arch/x86/xen/enlighten.c | 1 - arch/x86/xen/mmu.c | 2 -- 2 files changed, 3 deletions(-)
===================================================================
arch/x86/xen/enlighten.c +0 -1
@@ -25,7 +25,6 @@#include <linux/mm.h> #include <linux/page-flags.h> #include <linux/highmem.h> -#include <linux/smp.h> #include <xen/interface/xen.h> #include <xen/interface/physdev.h>
arch/x86/xen/mmu.c +0 -0
===================================================================
arch/x86/xen/mmu.c +0 -1
@@ -41,7 +41,6 @@#include <linux/sched.h> #include <linux/highmem.h> #include <linux/bug.h> -#include <linux/sched.h> #include <asm/pgtable.h> #include <asm/tlbflush.h>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/12] Clean up duplicate includes in arch/i386/xen/
Quoted 3 lines · Jeremy Fitzhardinge
This patch cleans up duplicate includes in
arch/i386/xen/
Just for the record; this patch is
From: Jesper Juhl <[email protected]>
Quoted 31 lines
Signed-off-by Jesper Juhl <[email protected]>Signed-off-by Jeremy Fitzhardinge <[email protected]>--- arch/x86/xen/enlighten.c | 1 - arch/x86/xen/mmu.c | 2 -- 2 files changed, 3 deletions(-)===================================================================
arch/x86/xen/enlighten.c +0
-1@@ -25,7 +25,6 @@#include <linux/mm.h> #include <linux/page-flags.h> #include <linux/highmem.h> -#include <linux/smp.h> #include <xen/interface/xen.h> #include <xen/interface/physdev.h> arch/x86/xen/mmu.c +0
-0===================================================================
arch/x86/xen/mmu.c +0
-1@@ -41,7 +41,6 @@#include <linux/sched.h> #include <linux/highmem.h> #include <linux/bug.h> -#include <linux/sched.h> #include <asm/pgtable.h> #include <asm/tlbflush.h>
Signature · 3 lines
Jesper Juhl <[email protected]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html
PATCH 5/12 xen: yield to IPI target if necessary
In reply to Jeremy FitzhardingeWhen sending a call-function IPI to a vcpu, yield if the vcpu isn't running.
--- arch/x86/xen/smp.c | 14 ++++++++++---- arch/x86/xen/time.c | 6 ++++++ arch/x86/xen/xen-ops.h | 2 ++ 3 files changed, 18 insertions(+), 4 deletions(-)
===================================================================
arch/x86/xen/smp.c +10 -4
@@ -360,7 +360,8 @@ int xen_smp_call_function_mask(cpumask_t void *info, int wait) {struct call_data_struct data; -int cpus; +int cpus, cpu; +bool yield;/* Holding any lock stops cpus from going down. */ spin_lock (&call_lock);
@@ -389,9 +390,14 @@ int xen_smp_call_function_mask(cpumask_t/* Send a message to other CPUs and wait for them to respond */ xen_send_IPI_mask (mask,XEN_CALL_FUNCTION_VECTOR ); -/* Make sure other vcpus get a chance to run. -XXX too severe? Maybe we should check the other CPU's states? */ -HYPERVISOR_sched_op (SCHEDOP_yield,0 ); +/* Make sure other vcpus get a chance to run if they need to. */ + yield = false; +for_each_cpu_mask (cpu, mask) +if (xen_vcpu_stolen (cpu)) + yield = true; + +if (yield) +HYPERVISOR_sched_op (SCHEDOP_yield,0 );/* Wait for response */ while (atomic_read(&data.started) != cpus ||
===================================================================
arch/x86/xen/time.c +6 -0
@@ -103,6 +103,12 @@ static void get_runstate_snapshot(struct *res = *state;barrier (); }while (get64 (&state->state_entry_time) != state_time); +} + +/* return true when a vcpu could run but has no real cpu to run on */ +bool xen_vcpu_stolen (int vcpu) +{ +return per_cpu (runstate, vcpu).state == RUNSTATE_runnable; }static void setup_runstate_info (int cpu)
===================================================================
arch/x86/xen/xen-ops.h +2 -0
@@ -27,6 +27,8 @@ int xen_set_wallclock(unsigned long timeint xen_set_wallclock (unsigned long time);unsigned long long xen_sched_clock (void ); +bool xen_vcpu_stolen (int vcpu); +void xen_mark_init_mm_pinned (void ); DECLARE_PER_CPU(enum paravirt_lazy_mode, xen_lazy_mode);
PATCH 6/12 xen: add batch completion callbacks
In reply to Jeremy FitzhardingeThis adds a mechanism to register a callback function to be called once a batch of hypercalls has been issued. This is typically used to unlock things which must remain locked until the hypercall has taken place.
[ Stable folks: pre-req for 2.6.23 bugfix "xen: deal with stale cr3
values when unpinning pagetables" ]
--- arch/x86/xen/multicalls.c | 29 ++++++++++++++++++++++++++--- arch/x86/xen/multicalls.h | 3 +++ 2 files changed, 29 insertions(+), 3 deletions(-)
===================================================================
arch/x86/xen/multicalls.c +26 -3
@@ -32,7 +32,11 @@ struct mc_buffer {struct mc_buffer {struct multicall_entry entries[MC_BATCH ];u64 args[MC_ARGS ]; -unsigned mcidx, argidx; +struct callback { +void (*fn)(void *); +void *data; + } callbacks[MC_BATCH ]; +unsigned mcidx, argidx, cbidx; }; static DEFINE_PER_CPU(struct mc_buffer, mc_buffer);
@@ -43,6 +47,7 @@ void xen_mc_flush(void)struct mc_buffer *b = &__get_cpu_var (mc_buffer);int ret =0 ;unsigned long flags; +int i;BUG_ON (preemptible ());
@@ -51,8 +56,6 @@ void xen_mc_flush(void)local_irq_save (flags);if (b->mcidx) { -int i; -if (HYPERVISOR_multicall (b->entries, b->mcidx) !=0 )BUG ();for (i =0 ; i < b->mcidx; i++)
@@ -64,6 +67,13 @@ void xen_mc_flush(void)BUG_ON (b->argidx !=0 );local_irq_restore (flags); + +for (i =0 ; i < b->cbidx; i++) { +struct callback *cb = &b->callbacks[i]; + + (*cb->fn)(cb->data); + } + b->cbidx =0 ;BUG_ON (ret); }
@@ -88,3 +98,16 @@ struct multicall_space __xen_mc_entry(sireturn ret; } + +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 ) +xen_mc_flush (); + + cb = &b->callbacks[b->cbidx++]; + cb->fn = fn; + cb->data = data; +}
===================================================================
arch/x86/xen/multicalls.h +3 -0
@@ -42,4 +42,7 @@ static inline void xen_mc_issue(unsigned local_irq_restore(x86_read_percpu(xen_mc_irq_flags)); } +/* Set up a callback to be called when the current batch is flushed */ +void xen_mc_callback (void (*fn)(void *),void *data); +#endif /* _XEN_MULTICALLS_H */
PATCH 7/12 xen: deal with stale cr3 values when unpinning pagetables
In reply to Jeremy FitzhardingeWhen a pagetable is no longer in use, it must be unpinned so that its pages can be freed. However, this is only possible if there are no stray uses of the pagetable. The code currently deals with all the usual cases, but there's a rare case where a vcpu is changing cr3, but is doing so lazily, and the change hasn't actually happened by the time the pagetable is unpinned, even though it appears to have been completed.
This change adds a second per-cpu cr3 variable - xen_current_cr3 - which tracks the actual state of the vcpu cr3. It is only updated once the actual hypercall to set cr3 has been completed. Other processors wishing to unpin a pagetable can check other vcpu's xen_current_cr3 values to see if any cross-cpu IPIs are needed to clean things up.
[ Stable folks: 2.6.23 bugfix ]
--- arch/x86/xen/enlighten.c | 63 ++++++++++++++++++++++++++++++---------------- arch/x86/xen/mmu.c | 33 ++++++++++++++++++++---- arch/x86/xen/xen-ops.h | 1 3 files changed, 71 insertions(+), 26 deletions(-)
===================================================================
arch/x86/xen/enlighten.c +42 -21
@@ -55,7 +55,23 @@ DEFINE_PER_CPU(enum paravirt_lazy_mode, DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu); DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info); -DEFINE_PER_CPU(unsigned long, xen_cr3); + +/* +* Note about cr3 (pagetable base) values: +* +* xen_cr3 contains the current logical cr3 value; it contains the +* last set cr3. This may not be the current effective cr3, because +* its update may be being lazily deferred. However, a vcpu looking +* at its own cr3 can use this value knowing that it everything will +* be self-consistent. +* +* xen_current_cr3 contains the actual vcpu cr3; it is set once the +* hypercall to set the vcpu cr3 is complete (so it may be a little +* out of date, but it will never be set early). If one vcpu is +* looking at another vcpu's cr3 value, it should use this variable. +*/ +DEFINE_PER_CPU(unsigned long, xen_cr3); /* cr3 stored as physaddr */ +DEFINE_PER_CPU(unsigned long, xen_current_cr3); /* actual vcpu cr3 */struct start_info *xen_start_info;EXPORT_SYMBOL_GPL (xen_start_info);
@@ -631,32 +647,36 @@ static unsigned long xen_read_cr3(void)return x86_read_percpu (xen_cr3); } +static void set_current_cr3 (void *v) +{ +x86_write_percpu (xen_current_cr3, (unsigned long )v); +} +static void xen_write_cr3 (unsigned long cr3) { +struct mmuext_op *op; +struct multicall_space mcs; +unsigned long mfn =pfn_to_mfn (PFN_DOWN (cr3)); +BUG_ON (preemptible ()); -if (cr3 ==x86_read_percpu (xen_cr3)) { -/* just a simple tlb flush */ -xen_flush_tlb (); -return ; - } - + mcs =xen_mc_entry (sizeof (*op));/* disables interrupts */ + +/* Update while interrupts are disabled, so its atomic with +respect to ipis */ x86_write_percpu (xen_cr3, cr3); - - { -struct mmuext_op *op; -struct multicall_space mcs =xen_mc_entry (sizeof (*op)); -unsigned long mfn =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 ); - -xen_mc_issue (PARAVIRT_LAZY_CPU ); - } + op = mcs.args; + op->cmd =MMUEXT_NEW_BASEPTR ; + op->arg1.mfn = mfn; + +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 );/* interrupts restored */ }/* Early in boot, while setting up the initial pagetable, assume
@@ -1124,6 +1144,7 @@ asmlinkage void __init xen_start_kernel(/* keep using Xen gdt for now; no urgent need to change it */ x86_write_percpu (xen_cr3,__pa (pgd)); +x86_write_percpu (xen_current_cr3,__pa (pgd));#ifdef CONFIG_SMP /* Don't do the full vcpu_info placement stuff until we have a
===================================================================
arch/x86/xen/mmu.c +28 -5
@@ -564,20 +564,43 @@ static void drop_other_mm_ref(void *infoif (__get_cpu_var (cpu_tlbstate).active_mm == mm)leave_mm (smp_processor_id ()); + +/* If this cpu still has a stale cr3 reference, then make sure +it has been flushed. */ +if (x86_read_percpu (xen_current_cr3) ==__pa (mm->pgd)) { +load_cr3 (swapper_pg_dir); +arch_flush_lazy_cpu_mode (); + } }static void drop_mm_ref (struct mm_struct *mm) { +cpumask_t mask; +unsigned cpu; +if (current->active_mm == mm) {if (current->mm == mm)load_cr3 (swapper_pg_dir);else leave_mm (smp_processor_id ()); - } - -if (!cpus_empty (mm->cpu_vm_mask)) -xen_smp_call_function_mask (mm->cpu_vm_mask, drop_other_mm_ref, - mm,1 ); +arch_flush_lazy_cpu_mode (); + } + +/* Get the "official" set of cpus referring to our pagetable. */ + mask = mm->cpu_vm_mask; + +/* It's possible that a vcpu may have a stale reference to our +cr3, because its in lazy mode, and it hasn't yet flushed +its set of pending hypercalls yet. In this case, we can +look at its actual current cr3 value, and force it to flush +if needed. */ +for_each_online_cpu (cpu) { +if (per_cpu (xen_current_cr3, cpu) ==__pa (mm->pgd)) +cpu_set (cpu, mask); + } + +if (!cpus_empty (mask)) +xen_smp_call_function_mask (mask, drop_other_mm_ref, mm,1 ); }#else static void drop_mm_ref (struct mm_struct *mm)
===================================================================
arch/x86/xen/xen-ops.h +1 -0
@@ -11,6 +11,7 @@ void xen_copy_trap_info(struct trap_info DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu); DECLARE_PER_CPU(unsigned long, xen_cr3); +DECLARE_PER_CPU(unsigned long, xen_current_cr3);extern struct start_info *xen_start_info;extern struct shared_info *HYPERVISOR_shared_info;
PATCH 8/12 xen: lock pte pages while pinning/unpinning
In reply to Jeremy FitzhardingeWhen a pagetable is created, it is made globally visible in the rmap prio tree before it is pinned via arch_dup_mmap(), and remains in the rmap tree while it is unpinned with arch_exit_mmap().
This means that other CPUs may race with the pinning/unpinning process, and see a pte between when it gets marked RO and actually pinned, causing any pte updates to fail with write-protect faults.
As a result, all pte pages must be properly locked, and only unlocked once the pinning/unpinning process has finished.
In order to avoid taking spinlocks for the whole pagetable - which may overflow the PREEMPT_BITS portion of preempt counter - it locks and pins each pte page individually, and then finally pins the whole pagetable.
--- arch/x86/xen/enlighten.c | 30 ++++++++---- arch/x86/xen/mmu.c | 113 +++++++++++++++++++++++++++++++++------------- mm/Kconfig | 1 3 files changed, 103 insertions(+), 41 deletions(-)
===================================================================
arch/x86/xen/enlighten.c +21 -9
@@ -687,6 +687,15 @@ static __init void xen_alloc_pt_init(strmake_lowmem_page_readonly (__va (PFN_PHYS (pfn))); } +static void pin_pagetable_pfn (unsigned level,unsigned long pfn) +{ +struct mmuext_op op; + op.cmd = level; + op.arg1.mfn =pfn_to_mfn (pfn); +if (HYPERVISOR_mmuext_op (&op,1 ,NULL ,DOMID_SELF )) +BUG (); +} +/* This needs to make sure the new pte page is pinned iff its being attached to a pinned pagetable. */ static void xen_alloc_pt (struct mm_struct *mm,u32 pfn)
@@ -696,9 +705,10 @@ static void xen_alloc_pt(struct mm_strucif (PagePinned (virt_to_page (mm->pgd))) {SetPagePinned (page); -if (!PageHighMem (page)) +if (!PageHighMem (page)) {make_lowmem_page_readonly (__va (PFN_PHYS (pfn))); -else +pin_pagetable_pfn (MMUEXT_PIN_L1_TABLE , pfn); + }else /* make sure there are no stray mappings of this page */ kmap_flush_unused ();
@@ -711,8 +721,10 @@ static void xen_release_pt(u32 pfn)struct page *page =pfn_to_page (pfn);if (PagePinned (page)) { -if (!PageHighMem (page)) +if (!PageHighMem (page)) { +pin_pagetable_pfn (MMUEXT_UNPIN_TABLE , pfn);make_lowmem_page_readwrite (__va (PFN_PHYS (pfn))); + } } }
@@ -827,15 +839,15 @@ static __init void xen_pagetable_setup_d/* Actually pin the pagetable down, but we can't set PG_pinned yet because the page structures don't exist yet. */ { -struct mmuext_op op; +unsigned level; +#ifdef CONFIG_X86_PAE - op.cmd =MMUEXT_PIN_L3_TABLE ; + level =MMUEXT_PIN_L3_TABLE ;#else - op.cmd =MMUEXT_PIN_L3_TABLE ; + level =MMUEXT_PIN_L2_TABLE ;#endif - op.arg1.mfn =pfn_to_mfn (PFN_DOWN (__pa (base))); -if (HYPERVISOR_mmuext_op (&op,1 ,NULL ,DOMID_SELF )) -BUG (); + +pin_pagetable_pfn (level,PFN_DOWN (__pa (base))); } }
===================================================================
arch/x86/xen/mmu.c +82 -31
211 lines not on this page · raw message
===================================================================
mm/Kconfig +0 -1
@@ -137,7 +137,6 @@ config SPLIT_PTLOCK_CPUS int default "4096" if ARM && !CPU_CACHE_VIPT default "4096" if PARISC && !PA20 - default "4096" if XEN default "4" #
PATCH 9/12 xen: ask the hypervisor how much space it needs reserved
In reply to Jeremy FitzhardingeAsk the hypervisor how much space it needs reserved, since 32-on-64 doesn't need any space, and it may change in future.
--- arch/x86/xen/enlighten.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
===================================================================
arch/x86/xen/enlighten.c +12 -1
@@ -1085,6 +1085,17 @@ static const struct machine_ops __initda }; +static void __init xen_reserve_top (void ) +{ +unsigned long top =HYPERVISOR_VIRT_START ; +struct xen_platform_parameters pp; + +if (HYPERVISOR_xen_version (XENVER_platform_parameters, &pp) ==0 ) + top = pp.virt_start; + +reserve_top_address (-top +2 *PAGE_SIZE ); +} +/* First C function to be called on Xen boot */ asmlinkage void __init xen_start_kernel(void) {
@@ -1134,7 +1145,7 @@ asmlinkage void __init xen_start_kernel( paravirt_ops.kernel_rpl =0 ;/* set the limit of our address space */ -reserve_top_address (-HYPERVISOR_VIRT_START +2 *PAGE_SIZE ); +xen_reserve_top ();/* set up basic CPUID stuff */ cpu_detect (&new_cpu_data);
PATCH 10/12 xen: fix incorrect vcpu_register_vcpu_info hypercall argument
In reply to Jeremy FitzhardingeThe kernel's copy of struct vcpu_register_vcpu_info was out of date, at best causing the hypercall to fail and the guest kernel to fall back to the old mechanism, or worse, causing random memory corruption.
[ Stable folks: applies to 2.6.23 ]
--- arch/x86/xen/enlighten.c | 2 +- include/xen/interface/vcpu.h | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-)
===================================================================
arch/x86/xen/enlighten.c +1 -1
@@ -115,7 +115,7 @@ static void __init xen_vcpu_setup(int cp info.mfn =virt_to_mfn (vcpup); info.offset =offset_in_page (vcpup); -printk (KERN_DEBUG "trying to map vcpu_info %d at %p, mfn %x, offset %d\n" , +printk (KERN_DEBUG "trying to map vcpu_info %d at %p, mfn %llx, offset %d\n" , cpu, vcpup, info.mfn, info.offset);/* Check to see if the hypervisor will put the vcpu_info
===================================================================
include/xen/interface/vcpu.h +3 -2
@@ -160,8 +160,9 @@ struct vcpu_set_singleshot_timer {*/ #define VCPUOP_register_vcpu_info 10/* arg == struct vcpu_info */ struct vcpu_register_vcpu_info { -uint32_t mfn;/* mfn of page to place vcpu_info */ -uint32_t offset;/* offset within page */ +uint64_t mfn;/* mfn of page to place vcpu_info */ +uint32_t offset;/* offset within page */ +uint32_t rsvd;/* unused */ };#endif /* __XEN_PUBLIC_VCPU_H__ */
PATCH 11/12 xen: add some debug output for failed multicalls
In reply to Jeremy FitzhardingeMulticalls are expected to never fail, and the normal response to a failed multicall is very terse. In the interests of better debuggability, add some more verbose output. It may be worth turning this off once it all seems more tested.
--- arch/x86/xen/multicalls.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
===================================================================
arch/x86/xen/multicalls.c +25 -0
@@ -26,11 +26,16 @@#include "multicalls.h" +#define MC_DEBUG 1 +#define MC_BATCH 32#define MC_ARGS (MC_BATCH * 16 / sizeof(u64))struct mc_buffer {struct multicall_entry entries[MC_BATCH ]; +#if MC_DEBUG +struct multicall_entry debug[MC_BATCH ]; +#endif u64 args[MC_ARGS ];struct callback {void (*fn)(void *);
@@ -56,11 +61,31 @@ void xen_mc_flush(void)local_irq_save (flags);if (b->mcidx) { +#if MC_DEBUG +memcpy (b->debug, b->entries, + b->mcidx *sizeof (struct multicall_entry )); +#endif +if (HYPERVISOR_multicall (b->entries, b->mcidx) !=0 )BUG ();for (i =0 ; i < b->mcidx; i++)if (b->entries[i].result <0 ) ret++; + +#if MC_DEBUG +if (ret) { +printk (KERN_ERR "%d multicall(s) failed: cpu %d\n" , + ret,smp_processor_id ()); +for (i =0 ; i < b->mcidx; i++) { +printk (" call %2d/%d: op=%lu arg=[%lx] result=%ld\n" , + i+1 , b->mcidx, + b->debug[i].op, + b->debug[i].args[0 ], + b->entries[i].result); + } + } +#endif + b->mcidx =0 ; b->argidx =0 ; }else
PATCH 12/12 xfs: eagerly remove vmap mappings to avoid upsetting Xen
In reply to Jeremy FitzhardingeXFS leaves stray mappings around when it vmaps memory to make it virtually contigious. This upsets Xen if one of those pages is being recycled into a pagetable, since it finds an extra writable mapping of the page.
This patch solves the problem in a brute force way, by making XFS always eagerly unmap its mappings. David Chinner says this shouldn't have any performance impact on filesystems with default block sizes; it will only affect filesystems with large block sizes.
--- fs/xfs/linux-2.6/xfs_buf.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
===================================================================
fs/xfs/linux-2.6/xfs_buf.c +13 -0
@@ -186,6 +186,19 @@ free_address( void *addr) {a_list_t *aentry; + +#ifdef CONFIG_XEN +/* +* Xen needs to be able to make sure it can get an exclusive +* RO mapping of pages it wants to turn into a pagetable. If +* a newly allocated page is also still being vmap()ed by xfs, +* it will cause pagetable construction to fail. This is a +* quick workaround to always eagerly unmap pages so that Xen +* is happy. +*/ +vunmap (addr); +return ; +#endif aentry =kmalloc (sizeof (a_list_t),GFP_NOWAIT );if (likely (aentry)) {
Re: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid upsetting Xen
Quoted 9 lines · Jeremy Fitzhardinge
XFS leaves stray mappings around when it vmaps memory to make it virtually contigious. This upsets Xen if one of those pages is being recycled into a pagetable, since it finds an extra writable mapping of the page.
This patch solves the problem in a brute force way, by making XFS always eagerly unmap its mappings. David Chinner says this shouldn't have any performance impact on filesystems with default block sizes; it will only affect filesystems with large block sizes.
Looks fine, Jeremy. I'll pull this into our dev tree and it should get pushed with the .24 XFS merge (if someone doesn't pull these patches directly).
Cheers,
Dave.
Signature · 3 lines
Dave Chinner Principal Engineer SGI Australian Software Group
Quoted 25 lines · Jeremy Fitzhardinge
Hi Linus,
Here's a set of patches to update
paravirt_opsand Xen for 2.6.24A quick overview of the patchset:
paravirt_ops:
Remove the monolithicparavirt_opsstructure, 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 codeXen:
- remove duplicate includes
- yield if the target vcpu of an IPI is not currently running
- add post-batch callbacks for multicalls [*]
- deal with unpinning pagetables when another vcpu still [*] has a cr3 reference
- deal with split ptelocks by pinning each pte page separately under lock
- determine the kernel/hypervisor address split dynamically
- use the right arg structure forregister_vcpu_info[*]
- add extra debugging output for failed multicalls
Quoted 4 lines
XFS:
- eagerly unmap vmapped areas to avoid confict with Xen[*] bugfix needed for 2.6.23. I've also cc:d them to [email protected]
Yeah, but you cc:ed all 12 patches to stable@. The majority of which we don't want to take, right? Which specific ones should stable@ care about?
thanks,
greg k-h
Quoted 3 lines · Greg KH
Yeah, but you cc:ed all 12 patches to stable@. The majority of which we don't want to take, right? Which specific ones should stable@ care about?
Crap, sorry about that. I'd just intended to send the overview and the four patches, which have explicit CC: stable lines in the patch descriptions. They are:
Subject: [PATCH 06/12] xen: add batch completion callbacks
Subject: [PATCH 07/12] xen: deal with stale cr3 values when unpinning pagetables
Subject: [PATCH 10/12] xen: fix incorrect vcpu_register_vcpu_info hypercall argument
Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid upsetting Xen
J
Quoted 3 lines
Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid upsetting Xen
This should be probably done unconditionally because it's a undefined dangerous condition everywhere.
-Andi
Quoted 5 lines · Andi Kleen
Quoted 2 lines
Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid upsetting Xen
This should be probably done unconditionally because it's a undefined dangerous condition everywhere.
Should be done unconditionally. One could remap the underlying physical space to include an MMIO region, and speculative reads from the cacheable virtual mapping of that region could move the robot arm, destroying the world.
Zach
Quoted 9 lines · Jeremy Fitzhardinge
Quoted 3 lines · Greg KH
Yeah, but you cc:ed all 12 patches to stable@. The majority of which we don't want to take, right? Which specific ones should stable@ care about?
Crap, sorry about that. I'd just intended to send the overview and the four patches, which have explicit CC: stable lines in the patch descriptions. They are:
Quoted 7 lines
Subject: [PATCH 06/12] xen: add batch completion callbacks
Subject: [PATCH 07/12] xen: deal with stale cr3 values when unpinning pagetables
Subject: [PATCH 10/12] xen: fix incorrectvcpu_register_vcpu_infohypercall argument
Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid upsetting Xen
These don't apply now due to the x86 merge. Care to backport them and send them to the [email protected] address so we can apply them properly?
thanks,
greg k-h
Quoted 3 lines
Quoted 3 lines
Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid upsetting Xen
This patch was the wrong fix anyways as discussed; David Chinner finally came up with a better one.
-Andi
Quoted 6 lines · Andi Kleen
Quoted 3 lines
Quoted 3 lines
Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid upsetting Xen
This patch was the wrong fix anyways as discussed; David Chinner finally came up with a better one.
Ok, that's good to know, if someone wants to send me the correct one, that would be appreciated.
Although, it's not like anyone actually uses the in-kernel Xen on 2.6.23, so it's probably not really worth it.
thanks,
greg k-h
Quoted 3 lines · Greg KH
These don't apply now due to the x86 merge. Care to backport them and send them to the [email protected] address so we can apply them properly?
I'm a bit confused. The patches you mailed out are against arch/i386. Won't they apply to the stable tree as-is?
Quoted 3 lines
Although, it's not like anyone actually uses the in-kernel Xen on 2.6.23, so it's probably not really worth it.
To be fair, those fixes were in response to bug reports raised on the released 2.6.23 kernel. But it isn't screamingly urgent.
J
Quoted 7 lines · Jeremy Fitzhardinge
Quoted 3 lines · Greg KH
These don't apply now due to the x86 merge. Care to backport them and send them to the [email protected] address so we can apply them properly?
I'm a bit confused. The patches you mailed out are against
arch/i386. Won't they apply to the stable tree as-is?
Was this second series a new set, or a different one? I was assuming they were new patches, and that they too needed to be applied.
These patches were sent against the merged x86 tree, not the -stable tree with i386.
Quoted 6 lines
Quoted 3 lines
Although, it's not like anyone actually uses the in-kernel Xen on 2.6.23, so it's probably not really worth it.
To be fair, those fixes were in response to bug reports raised on the released 2.6.23 kernel. But it isn't screamingly urgent.
Ok, that's fine, but can you send some patches that I can apply? :)
thanks,
greg k-h
Quoted 1 line · Greg KH
Ok, that's fine, but can you send some patches that I can apply? :)
The patches you've already queued for stable are all that's needed. Including the xfs one, despite Andi's reservations about it; Dave Chinner has a better fix, but as far as I know he hasn't submitted it for stable, and the workaround is enough to get things going.
I have one additional patch; I'll send it shortly (once Linus picks it up...).
J
Quoted 7 lines · Jeremy Fitzhardinge
Quoted 1 line · Greg KH
Ok, that's fine, but can you send some patches that I can apply? :)
The patches you've already queued for stable are all that's needed. Including the xfs one, despite Andi's reservations about it; Dave Chinner has a better fix, but as far as I know he hasn't submitted it for stable, and the workaround is enough to get things going.
Great, thanks for verifying.
greg k-h