search for: invlpg

Hello, In processors supporting VPID I think we should invalidate the VPID mapping in the TLB after a shadow invlpg (in case EPT is turned off). Signed-off-by: Gianluca Guida <gianluca.guida@eu.citrix.com> Gianluca _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Simplify paging_invlpg when flush is not required. New ''flush'' parameter is added to paging_invlpg, to allow caller assigning whether flush check is required. It''s wasteful to always validate shadow linear mapping if caller doesn''t check return value at all. Signed-off-by Kevin Tian...

...tmpreg), "=&r" (cr4), "=&r" (cr4_orig) \ - : "i" (~X86_CR4_PGE) \ - : "memory"); \ - } while (0) +#include <mach_tlbflush.h> extern unsigned long pgkern_mask; @@ -49,9 +18,6 @@ extern unsigned long pgkern_mask; #define cpu_has_invlpg (boot_cpu_data.x86 > 3) -#define __flush_tlb_single(addr) \ - __asm__ __volatile__("invlpg %0": :"m" (*(char *) addr)) - #ifdef CONFIG_X86_INVLPG # define __flush_tlb_one(addr) __flush_tlb_single(addr) #else Index: linux-2.6.16-rc5/include/asm-i386/mach-vmi/mach_tlbflush...

...tmpreg), "=&r" (cr4), "=&r" (cr4_orig) \ - : "i" (~X86_CR4_PGE) \ - : "memory"); \ - } while (0) +#include <mach_tlbflush.h> extern unsigned long pgkern_mask; @@ -49,9 +18,6 @@ extern unsigned long pgkern_mask; #define cpu_has_invlpg (boot_cpu_data.x86 > 3) -#define __flush_tlb_single(addr) \ - __asm__ __volatile__("invlpg %0": :"m" (*(char *) addr)) - #ifdef CONFIG_X86_INVLPG # define __flush_tlb_one(addr) __flush_tlb_single(addr) #else Index: linux-2.6.16-rc5/include/asm-i386/mach-vmi/mach_tlbflush...

...> +#define NATIVE_IRQ_ENABLE "sti" > +#define NATIVE_READ_CR2 "mov %cr2, " _REG_RET > +#define NATIVE_READ_CR3 "mov %cr3, " _REG_RET > +#define NATIVE_WRITE_CR3 "mov " _REG_ARG1 ", %cr3" > +#define NATIVE_FLUSH_TLB_SINGLE "invlpg (" _REG_ARG1 ")" > +#define NATIVE_SWAPGS "swapgs" > +#define NATIVE_IRET "iret" > +#define NATIVE_QUEUED_SPIN_UNLOCK "movb $0, (" _REG_ARG1 ")" > + > /* > * Volatile isn't enough to prevent the compiler from reorde...

...DISABLE "cli" +#define NATIVE_IRQ_ENABLE "sti" +#define NATIVE_READ_CR2 "mov %cr2, " _REG_RET +#define NATIVE_READ_CR3 "mov %cr3, " _REG_RET +#define NATIVE_WRITE_CR3 "mov " _REG_ARG1 ", %cr3" +#define NATIVE_FLUSH_TLB_SINGLE "invlpg (" _REG_ARG1 ")" +#define NATIVE_SWAPGS "swapgs" +#define NATIVE_IRET "iret" +#define NATIVE_QUEUED_SPIN_UNLOCK "movb $0, (" _REG_ARG1 ")" + /* * Volatile isn't enough to prevent the compiler from reordering the * read/write functi...

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 --

...ome interesting projects but still have some questions about them: "Add support for 16-bit x86 assembly and real mode to the assembler and disassembler, for use by BIOS code. This includes both 16-bit instruction encodings as well as privileged instructions (lgdt, lldt, ltr, lmsw, clts, invd, invlpg, wbinvd, hlt, rdmsr, wrmsr, rdpmc, rdtsc) and the control and debug registers." Correct me if I'm mistaken, but isn't this already implemented in llvm mc? I haven't searched for every instruction part of these architectures but I was able find to some of the privileged instruction...

Dear All: I am pretty new to xen-devel, please correct me in the following. Assume we have the following terms GPT: guest page table SPT: shadow page table (Question a) When guest OS is running, is it always using SPT for address translation? If it is the case, how does guest OS refer and modify its own GPT content? It seems that there is a page table entry in SPT for the GPT page. (Question

...e NATIVE_WRITE_CR3 "mov " _REG_ARG1 ", %cr3" +#define NATIVE_READ_CR2 "mov %%cr2, " _REG_RET +#define NATIVE_READ_CR3 "mov %%cr3, " _REG_RET +#define NATIVE_WRITE_CR3 "mov " _REG_ARG1 ", %%cr3" #define NATIVE_FLUSH_TLB_SINGLE "invlpg (" _REG_ARG1 ")" #define NATIVE_SWAPGS "swapgs" #define NATIVE_IRET "iret" -- 2.13.6

...+++ b/arch/x86/kernel/paravirt_patch_64.c @@ -10,7 +10,6 @@ DEF_NATIVE(pv_mmu_ops, read_cr2, "movq %cr2, %rax"); DEF_NATIVE(pv_mmu_ops, read_cr3, "movq %cr3, %rax"); DEF_NATIVE(pv_mmu_ops, write_cr3, "movq %rdi, %cr3"); DEF_NATIVE(pv_mmu_ops, flush_tlb_single, "invlpg (%rdi)"); -DEF_NATIVE(pv_cpu_ops, wbinvd, "wbinvd"); DEF_NATIVE(pv_cpu_ops, usergs_sysret64, "swapgs; sysretq"); DEF_NATIVE(pv_cpu_ops, swapgs, "swapgs"); @@ -60,7 +59,6 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf, PATCH_SITE(pv_mmu_ops, read...

Hi, Patch below is needed to make my system work stable in PAE mode. Havn''t seen problems without PAE, not sure whenever thats just pure luck or whenever there is a bug in my PAE xenlinux kernel. To me it looks like a generic bug though. I''ve actually trapped into problems with unpin only: A process exits, somewhere in exit_mm() the page tables are unpinned, shortly thereafter

Hi Zach, I'm wondering what the interface requirements of set_pte_at()'s "addr" and "ptep" args are. I presume that in general the ptep points to the pte entry which corresponds to the vaddr, but is this necessarily the case? For example, it is valid to pass a non-highmem page kmap_atomic(), which will simply return a direct pointer to the page. kunmap_atomic()

Hi Zach, I'm wondering what the interface requirements of set_pte_at()'s "addr" and "ptep" args are. I presume that in general the ptep points to the pte entry which corresponds to the vaddr, but is this necessarily the case? For example, it is valid to pass a non-highmem page kmap_atomic(), which will simply return a direct pointer to the page. kunmap_atomic()

Hi, This is an update to the paravirt_ops KVM backend series. I've made a number of changes and attempted to incorporate all the feedback from the last review. Some highlights: 1) Clean up the paravirt time source patch to use a more Xen-like model 2) Change the hypercall queueing to pass a PA on the flush hypercall 3) Add MMU support for release_{pt,pd} and TLB flush 4) Use KVM specific

Hi, This is an update to the paravirt_ops KVM backend series. I've made a number of changes and attempted to incorporate all the feedback from the last review. Some highlights: 1) Clean up the paravirt time source patch to use a more Xen-like model 2) Change the hypercall queueing to pass a PA on the flush hypercall 3) Add MMU support for release_{pt,pd} and TLB flush 4) Use KVM specific

...ATCH_SITE(pv_mmu_ops, write_cr3); diff --git a/arch/x86/kernel/paravirt_patch_64.c b/arch/x86/kernel/paravirt_patch_64.c index 8aa0558..17c00f8 100644 --- a/arch/x86/kernel/paravirt_patch_64.c +++ b/arch/x86/kernel/paravirt_patch_64.c @@ -13,7 +13,6 @@ DEF_NATIVE(pv_mmu_ops, flush_tlb_single, "invlpg (%rdi)"); DEF_NATIVE(pv_cpu_ops, clts, "clts"); DEF_NATIVE(pv_cpu_ops, wbinvd, "wbinvd"); -DEF_NATIVE(pv_cpu_ops, irq_enable_sysexit, "swapgs; sti; sysexit"); DEF_NATIVE(pv_cpu_ops, usergs_sysret64, "swapgs; sysretq"); DEF_NATIVE(pv_cpu_ops, usergs...

Here is an slightly updated version of the paravirt_ops patch. If your comments and criticism were welcome before, now it's even more! There are some issues that are _not_ addressed in this revision, and here are the causes: * split debugreg into multiple functions, suggested by Andi: - Me and jsfg agree that introducing more pvops (specially 14!) is not worthwhile. So, although we do

Here is an slightly updated version of the paravirt_ops patch. If your comments and criticism were welcome before, now it's even more! There are some issues that are _not_ addressed in this revision, and here are the causes: * split debugreg into multiple functions, suggested by Andi: - Me and jsfg agree that introducing more pvops (specially 14!) is not worthwhile. So, although we do