Displaying 20 results from an estimated 1000 matches similar to: "how set_pte_at()'s vaddr and ptep args relate"
2007 Apr 18
1
[PATCH 6/9] 00mm9 optimize ptep establish for pae.patch
The ptep_establish macro is only used on user-level PTEs, for P->P mapping
changes. Since these always happen under protection of the pagetable lock, the
strong synchronization of a 64-bit cmpxchg is not needed, in fact, not
even a lock prefix needs to be used. We can simply instead clear the P-bit,
followed by a normal set. The write ordering is still important to avoid the
possibility of
2020 Aug 15
0
[PATCH v4 5/6] x86/paravirt: remove set_pte_at pv-op
On x86 set_pte_at() is now always falling back to set_pte(). So instead
of having this fallback after the paravirt maze just drop the
set_pte_at paravirt operation and let set_pte_at() use the set_pte()
function directly.
Signed-off-by: Juergen Gross <jgross at suse.com>
---
arch/x86/include/asm/paravirt.h | 8 +-------
arch/x86/include/asm/paravirt_types.h | 2 --
2007 Apr 18
2
pte_offset_map + lazy mmu
Is pte_offset_map allowed to happen within lazy mmu? I presume not,
because you definitely don't want the mapping pte update to be deferred.
Or, more specifically, is kunmap_atomic ever allowed within lazy mmu?
I'm looking at kpte_clear_flush; I've already got a patch which turns
this into a pv_op, along with a Xen implementation. But I think its
probably an excess pv_op for a
2007 Apr 18
2
pte_offset_map + lazy mmu
Is pte_offset_map allowed to happen within lazy mmu? I presume not,
because you definitely don't want the mapping pte update to be deferred.
Or, more specifically, is kunmap_atomic ever allowed within lazy mmu?
I'm looking at kpte_clear_flush; I've already got a patch which turns
this into a pv_op, along with a Xen implementation. But I think its
probably an excess pv_op for a
2020 Aug 15
6
[PATCH v4 0/6] x86/paravirt: cleanup after 32-bit PV removal
A lot of cleanup after removal of 32-bit Xen PV guest support in
paravirt code.
Changes in V4:
- dropped patches 1-3, as already committed
- addressed comments to V3
- added new patches 5+6
Changes in V3:
- addressed comments to V2
- split patch 1 into 2 patches
- new patches 3 and 7
Changes in V2:
- rebase to 5.8 kernel
- addressed comments to V1
- new patches 3 and 4
Juergen Gross (6):
2007 Apr 18
2
[PATCH 5/6] i386 virtualization - Make generic set wrprotect a macro
On Mon, Aug 15, 2005 at 04:00:39PM -0700, zach@vmware.com wrote:
> Make the generic version of ptep_set_wrprotect a macro. This is good for
> code uniformity, and fixes the build for architectures which include pgtable.h
> through headers into assembly code, but do not define a ptep_set_wrprotect
> function.
This against the kernel coding style.
In fact, we are usually doing
2007 Apr 18
2
[PATCH 5/6] i386 virtualization - Make generic set wrprotect a macro
On Mon, Aug 15, 2005 at 04:00:39PM -0700, zach@vmware.com wrote:
> Make the generic version of ptep_set_wrprotect a macro. This is good for
> code uniformity, and fixes the build for architectures which include pgtable.h
> through headers into assembly code, but do not define a ptep_set_wrprotect
> function.
This against the kernel coding style.
In fact, we are usually doing
2007 Apr 18
17
[patch 00/17] paravirt_ops updates
Hi Andi,
This series of patches updates paravirt_ops in various ways. Some of the
changes are plain cleanups and improvements, and some add some interfaces
necessary for Xen.
The brief overview:
add-MAINTAINERS.patch - obvious
remove-CONFIG_DEBUG_PARAVIRT.patch - no longer needed
paravirt-nop.patch - mark nop operations consistently
paravirt-pte-accessors.patch - operations to pack/unpack
2007 Apr 18
17
[patch 00/17] paravirt_ops updates
Hi Andi,
This series of patches updates paravirt_ops in various ways. Some of the
changes are plain cleanups and improvements, and some add some interfaces
necessary for Xen.
The brief overview:
add-MAINTAINERS.patch - obvious
remove-CONFIG_DEBUG_PARAVIRT.patch - no longer needed
paravirt-nop.patch - mark nop operations consistently
paravirt-pte-accessors.patch - operations to pack/unpack
2007 Apr 18
23
[patch 00/20] paravirt_ops updates
Hi Andi,
Here's a repost of the paravirt_ops update series I posted the other day.
Since then, I found a few potential bugs with patching clobbering,
cleaned up and documented paravirt.h and the patching machinery.
Overview:
add-MAINTAINERS.patch
obvious
remove-CONFIG_DEBUG_PARAVIRT.patch
No longer meaningful or needed.
paravirt-nop.patch
Clean up nop paravirt_ops functions, mainly to
2007 Apr 18
23
[patch 00/20] paravirt_ops updates
Hi Andi,
Here's a repost of the paravirt_ops update series I posted the other day.
Since then, I found a few potential bugs with patching clobbering,
cleaned up and documented paravirt.h and the patching machinery.
Overview:
add-MAINTAINERS.patch
obvious
remove-CONFIG_DEBUG_PARAVIRT.patch
No longer meaningful or needed.
paravirt-nop.patch
Clean up nop paravirt_ops functions, mainly to
2007 Apr 18
1
[RFC, PATCH 19/24] i386 Vmi mmu changes
MMU code movement. Unfortunately, this one is a little bit more
complicated than the rest. We have to override the default accessors
that directly write to page table entries. Because of the 2/3-level
PAE split in Linux, this turned out to be really ugly at first, but
by allowing the sub-arch layer to override the definitions and keeping
the native definitions in place, the code becomes much
2007 Apr 18
1
[RFC, PATCH 19/24] i386 Vmi mmu changes
MMU code movement. Unfortunately, this one is a little bit more
complicated than the rest. We have to override the default accessors
that directly write to page table entries. Because of the 2/3-level
PAE split in Linux, this turned out to be really ugly at first, but
by allowing the sub-arch layer to override the definitions and keeping
the native definitions in place, the code becomes much
2008 May 31
9
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction (take 2)
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),
2008 May 31
9
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction (take 2)
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),
2008 May 31
9
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction (take 2)
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),
2008 May 23
6
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction
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,
2008 May 23
6
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction
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,
2008 May 23
6
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction
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,
2017 Sep 04
0
[PATCH] x86/paravirt: remove no longer used paravirt functions
With removal of lguest some of the paravirt functions are no longer
needed. Remove them.
Signed-off-by: Juergen Gross <jgross at suse.com>
---
arch/x86/include/asm/desc.h | 3 +--
arch/x86/include/asm/paravirt.h | 37 -----------------------------------
arch/x86/include/asm/paravirt_types.h | 9 ---------
arch/x86/include/asm/pgtable.h | 27