similar to: [v1 1/1] xen, mm: Allow deferred page initialization for xen pv domains

Displaying 20 results from an estimated 800 matches similar to: "[v1 1/1] xen, mm: Allow deferred page initialization for xen pv domains"

2018 Feb 27
0
[v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains
* Pavel Tatashin <pasha.tatashin at oracle.com> wrote: > Juergen Gross noticed that commit > f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap") > broke XEN PV domains when deferred struct page initialization is enabled. > > This is because the xen's PagePinned() flag is getting erased from struct > pages when they are initialized later in
2018 Feb 27
0
[v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains
On 26/02/18 17:01, Pavel Tatashin wrote: > Juergen Gross noticed that commit > f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap") > broke XEN PV domains when deferred struct page initialization is enabled. > > This is because the xen's PagePinned() flag is getting erased from struct > pages when they are initialized later in boot. > >
2018 Aug 10
0
[PATCH 04/10] x86/paravirt: use a single ops structure
Instead of using six globally visible paravirt ops structures combine them in a single structure, keeping the original structures as sub-structures. This avoids the need to assemble struct paravirt_patch_template at runtime on the stack each time apply_paravirt() is being called (i.e. when loading a module). Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/hyperv/mmu.c
2013 Feb 22
3
[GIT PULL] x86/mm changes for v3.9-rc1
Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for
2013 Feb 22
3
[GIT PULL] x86/mm changes for v3.9-rc1
Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for
2013 Feb 22
3
[GIT PULL] x86/mm changes for v3.9-rc1
Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for
2013 Mar 10
1
[PATCH v2, part1 00/29] Use helper functions to simplify memory intialization code
The original goal of this patchset is to fix the bug reported by https://bugzilla.kernel.org/show_bug.cgi?id=53501 Now it has also been expanded to reduce common code used by memory initializion. This is the first part, which applies to v3.9-rc1. It introduces following common helper functions to simplify free_initmem() and free_initrd_mem() on different architectures:
2013 Mar 10
1
[PATCH v2, part1 00/29] Use helper functions to simplify memory intialization code
The original goal of this patchset is to fix the bug reported by https://bugzilla.kernel.org/show_bug.cgi?id=53501 Now it has also been expanded to reduce common code used by memory initializion. This is the first part, which applies to v3.9-rc1. It introduces following common helper functions to simplify free_initmem() and free_initrd_mem() on different architectures:
2007 Feb 14
2
[PATCH 8/8] 2.6.17: scan DMI early
While shuffling quite a few things around, this gets us closer to native, which clearly had a reason to do the DMI scan early. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-08/arch/i386/mm/ioremap-xen.c =================================================================== --- head-2007-02-08.orig/arch/i386/mm/ioremap-xen.c 2007-02-08 17:07:13.000000000 +0100 +++
2019 Jun 26
0
[PATCH 14/25] memremap: replace the altmap_valid field with a PGMAP_ALTMAP_VALID flag
Add a flags field to struct dev_pagemap to replace the altmap_valid boolean to be a little more extensible. Also add a pgmap_altmap() helper to find the optional altmap and clean up the code using the altmap using it. Signed-off-by: Christoph Hellwig <hch at lst.de> --- arch/powerpc/mm/mem.c | 10 +--------- arch/x86/mm/init_64.c | 8 ++------ drivers/nvdimm/pfn_devs.c | 3 +--
2019 Jul 03
0
[PATCH v2 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
> On Jul 3, 2019, at 7:04 AM, Juergen Gross <jgross at suse.com> wrote: > > On 03.07.19 01:51, Nadav Amit wrote: >> To improve TLB shootdown performance, flush the remote and local TLBs >> concurrently. Introduce flush_tlb_multi() that does so. Introduce >> paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen >> and hyper-v are only
2019 Jul 26
0
[PATCH AUTOSEL 5.2 79/85] x86/paravirt: Fix callee-saved function ELF sizes
From: Josh Poimboeuf <jpoimboe at redhat.com> [ Upstream commit 083db6764821996526970e42d09c1ab2f4155dd4 ] The __raw_callee_save_*() functions have an ELF symbol size of zero, which confuses objtool and other tools. Fixes a bunch of warnings like the following: arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation
2019 Jul 26
0
[PATCH AUTOSEL 4.19 45/47] x86/paravirt: Fix callee-saved function ELF sizes
From: Josh Poimboeuf <jpoimboe at redhat.com> [ Upstream commit 083db6764821996526970e42d09c1ab2f4155dd4 ] The __raw_callee_save_*() functions have an ELF symbol size of zero, which confuses objtool and other tools. Fixes a bunch of warnings like the following: arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation
2019 Jul 26
0
[PATCH AUTOSEL 4.14 35/37] x86/paravirt: Fix callee-saved function ELF sizes
From: Josh Poimboeuf <jpoimboe at redhat.com> [ Upstream commit 083db6764821996526970e42d09c1ab2f4155dd4 ] The __raw_callee_save_*() functions have an ELF symbol size of zero, which confuses objtool and other tools. Fixes a bunch of warnings like the following: arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation
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 --
2019 Jul 03
1
[Xen-devel] [PATCH v2 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
On 03/07/2019 18:02, Nadav Amit wrote: >> On Jul 3, 2019, at 7:04 AM, Juergen Gross <jgross at suse.com> wrote: >> >> On 03.07.19 01:51, Nadav Amit wrote: >>> To improve TLB shootdown performance, flush the remote and local TLBs >>> concurrently. Introduce flush_tlb_multi() that does so. Introduce >>> paravirtual versions of flush_tlb_multi() for
2023 Feb 07
1
[PATCH v2] x86/paravirt: merge activate_mm and dup_mmap callbacks
The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are sharing the same implementations in all cases: for Xen PV guests they are pinning the PGD of the new mm_struct, and for all other cases they are a NOP. In the end both callbacks are meant to register an address space with the underlying hypervisor, so there needs to be only a single callback for that purpose. So merge them to a
2019 Jul 03
2
[PATCH v2 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
On 03.07.19 01:51, Nadav Amit wrote: > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. Introduce > paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen > and hyper-v are only compile-tested). > > While the updated smp infrastructure is capable of running a function on > a single
2019 Jul 03
2
[PATCH v2 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
On 03.07.19 01:51, Nadav Amit wrote: > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. Introduce > paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen > and hyper-v are only compile-tested). > > While the updated smp infrastructure is capable of running a function on > a single
2016 Oct 19
0
[PATCH v4 5/5] x86, kvm: support vcpu preempted check
This is to fix some lock holder preemption issues. Some other locks implementation do a spin loop before acquiring the lock itself. Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It takes the cpu as parameter and return true if the cpu is preempted. Then kernel can break the spin loops upon on the retval of vcpu_is_preempted. As kernel has used this interface, So lets