search for: flush_tlb_all

...;& !PageHighMem(page)) { ret = HYPERVISOR_update_va_mapping( @@ -422,24 +426,19 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) BUG_ON(ret); } #endif - } - - /* Ensure that ballooned highmem pages don''t have kmaps. */ - kmap_flush_unused(); - flush_tlb_all(); - - /* No more mappings: invalidate P2M and add to balloon. */ - for (i = 0; i < nr_pages; i++) { - pfn = mfn_to_pfn(frame_list[i]); if (!xen_feature(XENFEAT_auto_translated_physmap)) { unsigned long p; p = page_to_pfn(scratch_page); __set_phys_to_machine(pfn, pfn_to_mfn(p));...

Hi all, Can Xen hypervisor modify HVM domU's Shadow page table, under the dom0's context, like trapped from dom0's hypercall? I think it have to call 2 functions at least: guest_walk_tables() and flush_tlb_all(). Can these 2 functions called in dom0's context? In my test, if hypervisor tries to modify HVM's shadow page table, it will bring down the whole system. I am not sure what's the reason. Thanks, Wu _______________________________________________ Xen-devel mailing list Xen-devel@list...

...8 23:24:43 2006 +0100 +++ b/linux-2.6-xen-sparse/drivers/xen/blktap/blktap.c Thu Sep 28 23:29:31 2006 +0100 @@ -680,7 +680,6 @@ static unsigned int blktap_poll(struct f poll_wait(file, &info->wait, wait); if (info->ufe_ring.req_prod_pvt != info->ufe_ring.sring->req_prod) { - flush_tlb_all(); RING_PUSH_REQUESTS(&info->ufe_ring); return POLLIN | POLLRDNORM; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

....c | 8 +++--- include/asm-i386/smp.h | 53 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 73 insertions(+), 9 deletions(-) =================================================================== --- a/arch/i386/kernel/smp.c +++ b/arch/i386/kernel/smp.c @@ -483,7 +483,7 @@ void flush_tlb_all(void) * it goes straight through and wastes no time serializing * anything. Worst case is that we lose a reschedule ... */ -void smp_send_reschedule(int cpu) +void native_smp_send_reschedule(int cpu) { WARN_ON(cpu_is_offline(cpu)); send_IPI_mask(cpumask_of_cpu(cpu), RESCHEDULE_VECTOR); @...

....c | 8 +++--- include/asm-i386/smp.h | 53 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 73 insertions(+), 9 deletions(-) =================================================================== --- a/arch/i386/kernel/smp.c +++ b/arch/i386/kernel/smp.c @@ -483,7 +483,7 @@ void flush_tlb_all(void) * it goes straight through and wastes no time serializing * anything. Worst case is that we lose a reschedule ... */ -void smp_send_reschedule(int cpu) +void native_smp_send_reschedule(int cpu) { WARN_ON(cpu_is_offline(cpu)); send_IPI_mask(cpumask_of_cpu(cpu), RESCHEDULE_VECTOR); @...

Hi, on IA64 flushing the whole TLB is very expensive: this is a cpu tlb flush and clearing 16MB of memory (virtual tlb). However, flushing an address range is rather cheap. Flushing an address range on every processors is also cheap (no IPI). Unfortunatly Xen common code flushes the whole TLB after unmapping grant reference. Currently, this is not done on IA64 because domain_dirty_cpumask

...e contiguous map. */ + ASSERT(((unsigned long) addr & PAGE_MASK) == LDT_VIRT_START(v)); + offset = l1_linear_offset((unsigned long) addr); + l1e_write(&__linear_l1_table[offset], l1e_empty()); + l1e_write(&__linear_l1_table[offset + 1], l1e_empty()); + flush_tlb_all(); + } +} + +static int hvm_x86_emulate_cmpxchg( + struct vcpu *v, + unsigned long vaddr, + unsigned long old, + unsigned long new, + unsigned int bytes) +{ + void *addr; + unsigned long prev; + int rc = X86EMUL_OKAY; + + addr = emulate_map_dest(v, vaddr, bytes); +...

...+ + __asm__ __volatile__("\tlidt %0": "=m" (idt_d)); + + /* + * Unmap lower page: + */ + pgd = pgd_offset(current->mm, twopage); + pmd = pmd_offset(pgd, twopage); + pte = pte_offset(pmd, twopage); + + pte_clear(pte); + flush_tlb_all(); + + printk(" ... done\n"); +} + + + __initfunc(void trap_init(void)) { int i; diff -u --recursive --new-file v2.1.62/linux/arch/i386/mm/fault.c linux/arch/i386/mm/fault.c - --- v2.1.62/linux/arch/i386/mm/fault.c Wed Oct 15 16:04:23 1997 +++ linux/arch/i386/mm/fault.c...

...ioremapping(); pr_info("All done.\n"); return 0; } diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 426f3a1..c03f14a 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -278,11 +278,9 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long va) static void do_flush_tlb_all(void *info) { - unsigned long cpu = smp_processor_id(); - __flush_tlb_all(); if (percpu_read(cpu_tlbstate.state) == TLBSTATE_LAZY) - leave_mm(cpu); + leave_mm(smp_processor_id()); } void flush_tlb_all(void) diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c index 02...

...+= smpcommon.o obj-$(CONFIG_X86_TRAMPOLINE) += trampoline.o obj-$(CONFIG_X86_MPPARSE) += mpparse.o obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o =================================================================== --- a/arch/i386/kernel/smp.c +++ b/arch/i386/kernel/smp.c @@ -468,7 +468,7 @@ void flush_tlb_all(void) * it goes straight through and wastes no time serializing * anything. Worst case is that we lose a reschedule ... */ -void native_smp_send_reschedule(int cpu) +static void native_smp_send_reschedule(int cpu) { WARN_ON(cpu_is_offline(cpu)); send_IPI_mask(cpumask_of_cpu(cpu), RESCHED...

...+= smpcommon.o obj-$(CONFIG_X86_TRAMPOLINE) += trampoline.o obj-$(CONFIG_X86_MPPARSE) += mpparse.o obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o =================================================================== --- a/arch/i386/kernel/smp.c +++ b/arch/i386/kernel/smp.c @@ -468,7 +468,7 @@ void flush_tlb_all(void) * it goes straight through and wastes no time serializing * anything. Worst case is that we lose a reschedule ... */ -void native_smp_send_reschedule(int cpu) +static void native_smp_send_reschedule(int cpu) { WARN_ON(cpu_is_offline(cpu)); send_IPI_mask(cpumask_of_cpu(cpu), RESCHED...

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the

Hi folks, Here is the result of the latest work on the pvops front, after the x86 arch merge. From the functionality point of view, almost nothing was changed, except for proper vsmp support - which was discussed, but not implemented before - and the introduction of smp_ops in x86_64, which eased the merging of the smp header. Speaking of the merge, a significant part (although not majority) of

Hi folks, Here is the result of the latest work on the pvops front, after the x86 arch merge. From the functionality point of view, almost nothing was changed, except for proper vsmp support - which was discussed, but not implemented before - and the introduction of smp_ops in x86_64, which eased the merging of the smp header. Speaking of the merge, a significant part (although not majority) of

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

I''m sure everyone has seen the drop of VMI patches for Linux at this point, but just in case, the link is included below. I''ve read this version of the VMI spec and have made my way through most of the patches. While I wasn''t really that impressed with the first spec wrt Xen, the second version seems to be much more palatable. Specifically, the code inlining and

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all