2007-07-18 01:37:04 +00:00
|
|
|
/*
|
|
|
|
* Xen mmu operations
|
|
|
|
*
|
|
|
|
* This file contains the various mmu fetch and update operations.
|
|
|
|
* The most important job they must perform is the mapping between the
|
|
|
|
* domain's pfn and the overall machine mfns.
|
|
|
|
*
|
|
|
|
* Xen allows guests to directly update the pagetable, in a controlled
|
|
|
|
* fashion. In other words, the guest modifies the same pagetable
|
|
|
|
* that the CPU actually uses, which eliminates the overhead of having
|
|
|
|
* a separate shadow pagetable.
|
|
|
|
*
|
|
|
|
* In order to allow this, it falls on the guest domain to map its
|
|
|
|
* notion of a "physical" pfn - which is just a domain-local linear
|
|
|
|
* address - into a real "machine address" which the CPU's MMU can
|
|
|
|
* use.
|
|
|
|
*
|
|
|
|
* A pgd_t/pmd_t/pte_t will typically contain an mfn, and so can be
|
|
|
|
* inserted directly into the pagetable. When creating a new
|
|
|
|
* pte/pmd/pgd, it converts the passed pfn into an mfn. Conversely,
|
|
|
|
* when reading the content back with __(pgd|pmd|pte)_val, it converts
|
|
|
|
* the mfn back into a pfn.
|
|
|
|
*
|
|
|
|
* The other constraint is that all pages which make up a pagetable
|
|
|
|
* must be mapped read-only in the guest. This prevents uncontrolled
|
|
|
|
* guest updates to the pagetable. Xen strictly enforces this, and
|
|
|
|
* will disallow any pagetable update which will end up mapping a
|
|
|
|
* pagetable page RW, and will disallow using any writable page as a
|
|
|
|
* pagetable.
|
|
|
|
*
|
|
|
|
* Naively, when loading %cr3 with the base of a new pagetable, Xen
|
|
|
|
* would need to validate the whole pagetable before going on.
|
|
|
|
* Naturally, this is quite slow. The solution is to "pin" a
|
|
|
|
* pagetable, which enforces all the constraints on the pagetable even
|
|
|
|
* when it is not actively in use. This menas that Xen can be assured
|
|
|
|
* that it is still valid when you do load it into %cr3, and doesn't
|
|
|
|
* need to revalidate it.
|
|
|
|
*
|
|
|
|
* Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
|
|
|
|
*/
|
2007-07-18 01:37:06 +00:00
|
|
|
#include <linux/sched.h>
|
2007-07-18 01:37:05 +00:00
|
|
|
#include <linux/highmem.h>
|
2008-08-21 00:02:19 +00:00
|
|
|
#include <linux/debugfs.h>
|
2007-07-18 01:37:04 +00:00
|
|
|
#include <linux/bug.h>
|
2010-03-26 22:37:50 +00:00
|
|
|
#include <linux/vmalloc.h>
|
2009-05-12 20:31:40 +00:00
|
|
|
#include <linux/module.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/gfp.h>
|
2010-08-25 20:39:17 +00:00
|
|
|
#include <linux/memblock.h>
|
2010-12-22 13:57:30 +00:00
|
|
|
#include <linux/seq_file.h>
|
2012-10-01 19:18:01 +00:00
|
|
|
#include <linux/crash_dump.h>
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2010-12-17 01:02:35 +00:00
|
|
|
#include <trace/events/xen.h>
|
|
|
|
|
2007-07-18 01:37:04 +00:00
|
|
|
#include <asm/pgtable.h>
|
|
|
|
#include <asm/tlbflush.h>
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
#include <asm/fixmap.h>
|
2007-07-18 01:37:04 +00:00
|
|
|
#include <asm/mmu_context.h>
|
2009-01-28 22:35:01 +00:00
|
|
|
#include <asm/setup.h>
|
2007-07-18 01:37:05 +00:00
|
|
|
#include <asm/paravirt.h>
|
2010-02-19 18:31:06 +00:00
|
|
|
#include <asm/e820.h>
|
2008-07-08 22:06:27 +00:00
|
|
|
#include <asm/linkage.h>
|
2009-02-09 20:05:46 +00:00
|
|
|
#include <asm/page.h>
|
2010-10-13 23:02:24 +00:00
|
|
|
#include <asm/init.h>
|
2010-03-30 18:47:40 +00:00
|
|
|
#include <asm/pat.h>
|
2009-12-18 09:31:31 +00:00
|
|
|
#include <asm/smp.h>
|
2007-07-18 01:37:04 +00:00
|
|
|
|
|
|
|
#include <asm/xen/hypercall.h>
|
2007-07-18 01:37:05 +00:00
|
|
|
#include <asm/xen/hypervisor.h>
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2010-02-04 22:46:34 +00:00
|
|
|
#include <xen/xen.h>
|
2007-07-18 01:37:04 +00:00
|
|
|
#include <xen/page.h>
|
|
|
|
#include <xen/interface/xen.h>
|
2010-06-17 13:22:52 +00:00
|
|
|
#include <xen/interface/hvm/hvm_op.h>
|
2009-01-28 22:35:01 +00:00
|
|
|
#include <xen/interface/version.h>
|
2010-02-04 22:46:34 +00:00
|
|
|
#include <xen/interface/memory.h>
|
2009-01-28 22:35:01 +00:00
|
|
|
#include <xen/hvc-console.h>
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
#include "multicalls.h"
|
2007-07-18 01:37:04 +00:00
|
|
|
#include "mmu.h"
|
2008-08-21 00:02:19 +00:00
|
|
|
#include "debugfs.h"
|
|
|
|
|
2009-02-09 20:05:46 +00:00
|
|
|
/*
|
|
|
|
* Protects atomic reservation decrease/increase against concurrent increases.
|
2011-03-08 21:45:46 +00:00
|
|
|
* Also protects non-atomic updates of current_pages and balloon lists.
|
2009-02-09 20:05:46 +00:00
|
|
|
*/
|
|
|
|
DEFINE_SPINLOCK(xen_reservation_lock);
|
|
|
|
|
2012-07-12 17:59:36 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
2009-01-28 22:35:01 +00:00
|
|
|
/*
|
|
|
|
* Identity map, in addition to plain kernel map. This needs to be
|
|
|
|
* large enough to allocate page table pages to allocate the rest.
|
|
|
|
* Each page can map 2MB.
|
|
|
|
*/
|
2010-08-26 23:23:51 +00:00
|
|
|
#define LEVEL1_IDENT_ENTRIES (PTRS_PER_PTE * 4)
|
|
|
|
static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);
|
2012-07-12 17:59:36 +00:00
|
|
|
#endif
|
2009-01-28 22:35:01 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
/* l3 pud for userspace vsyscall mapping */
|
|
|
|
static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
|
|
|
|
#endif /* CONFIG_X86_64 */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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 */
|
|
|
|
|
|
|
|
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
/*
|
|
|
|
* Just beyond the highest usermode address. STACK_TOP_MAX has a
|
|
|
|
* redzone above it, so round it up to a PGD boundary.
|
|
|
|
*/
|
|
|
|
#define USER_LIMIT ((STACK_TOP_MAX + PGDIR_SIZE - 1) & PGDIR_MASK)
|
|
|
|
|
2009-02-27 17:19:26 +00:00
|
|
|
unsigned long arbitrary_virt_to_mfn(void *vaddr)
|
|
|
|
{
|
|
|
|
xmaddr_t maddr = arbitrary_virt_to_machine(vaddr);
|
|
|
|
|
|
|
|
return PFN_DOWN(maddr.maddr);
|
|
|
|
}
|
|
|
|
|
2008-07-08 22:06:55 +00:00
|
|
|
xmaddr_t arbitrary_virt_to_machine(void *vaddr)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2008-07-08 22:06:55 +00:00
|
|
|
unsigned long address = (unsigned long)vaddr;
|
2008-02-09 22:24:08 +00:00
|
|
|
unsigned int level;
|
xen: fix Xen domU boot with batched mprotect
Impact: fix guest kernel boot crash on certain configs
Recent i686 2.6.27 kernels with a certain amount of memory (between
736 and 855MB) have a problem booting under a hypervisor that supports
batched mprotect (this includes the RHEL-5 Xen hypervisor as well as
any 3.3 or later Xen hypervisor).
The problem ends up being that xen_ptep_modify_prot_commit() is using
virt_to_machine to calculate which pfn to update. However, this only
works for pages that are in the p2m list, and the pages coming from
change_pte_range() in mm/mprotect.c are kmap_atomic pages. Because of
this, we can run into the situation where the lookup in the p2m table
returns an INVALID_MFN, which we then try to pass to the hypervisor,
which then (correctly) denies the request to a totally bogus pfn.
The right thing to do is to use arbitrary_virt_to_machine, so that we
can be sure we are modifying the right pfn. This unfortunately
introduces a performance penalty because of a full page-table-walk,
but we can avoid that penalty for pages in the p2m list by checking if
virt_addr_valid is true, and if so, just doing the lookup in the p2m
table.
The attached patch implements this, and allows my 2.6.27 i686 based
guest with 768MB of memory to boot on a RHEL-5 hypervisor again.
Thanks to Jeremy for the suggestions about how to fix this particular
issue.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-24 00:40:25 +00:00
|
|
|
pte_t *pte;
|
|
|
|
unsigned offset;
|
2007-07-18 01:37:04 +00:00
|
|
|
|
xen: fix Xen domU boot with batched mprotect
Impact: fix guest kernel boot crash on certain configs
Recent i686 2.6.27 kernels with a certain amount of memory (between
736 and 855MB) have a problem booting under a hypervisor that supports
batched mprotect (this includes the RHEL-5 Xen hypervisor as well as
any 3.3 or later Xen hypervisor).
The problem ends up being that xen_ptep_modify_prot_commit() is using
virt_to_machine to calculate which pfn to update. However, this only
works for pages that are in the p2m list, and the pages coming from
change_pte_range() in mm/mprotect.c are kmap_atomic pages. Because of
this, we can run into the situation where the lookup in the p2m table
returns an INVALID_MFN, which we then try to pass to the hypervisor,
which then (correctly) denies the request to a totally bogus pfn.
The right thing to do is to use arbitrary_virt_to_machine, so that we
can be sure we are modifying the right pfn. This unfortunately
introduces a performance penalty because of a full page-table-walk,
but we can avoid that penalty for pages in the p2m list by checking if
virt_addr_valid is true, and if so, just doing the lookup in the p2m
table.
The attached patch implements this, and allows my 2.6.27 i686 based
guest with 768MB of memory to boot on a RHEL-5 hypervisor again.
Thanks to Jeremy for the suggestions about how to fix this particular
issue.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-24 00:40:25 +00:00
|
|
|
/*
|
|
|
|
* if the PFN is in the linear mapped vaddr range, we can just use
|
|
|
|
* the (quick) virt_to_machine() p2m lookup
|
|
|
|
*/
|
|
|
|
if (virt_addr_valid(vaddr))
|
|
|
|
return virt_to_machine(vaddr);
|
|
|
|
|
|
|
|
/* otherwise we have to do a (slower) full page-table walk */
|
2007-07-18 01:37:04 +00:00
|
|
|
|
xen: fix Xen domU boot with batched mprotect
Impact: fix guest kernel boot crash on certain configs
Recent i686 2.6.27 kernels with a certain amount of memory (between
736 and 855MB) have a problem booting under a hypervisor that supports
batched mprotect (this includes the RHEL-5 Xen hypervisor as well as
any 3.3 or later Xen hypervisor).
The problem ends up being that xen_ptep_modify_prot_commit() is using
virt_to_machine to calculate which pfn to update. However, this only
works for pages that are in the p2m list, and the pages coming from
change_pte_range() in mm/mprotect.c are kmap_atomic pages. Because of
this, we can run into the situation where the lookup in the p2m table
returns an INVALID_MFN, which we then try to pass to the hypervisor,
which then (correctly) denies the request to a totally bogus pfn.
The right thing to do is to use arbitrary_virt_to_machine, so that we
can be sure we are modifying the right pfn. This unfortunately
introduces a performance penalty because of a full page-table-walk,
but we can avoid that penalty for pages in the p2m list by checking if
virt_addr_valid is true, and if so, just doing the lookup in the p2m
table.
The attached patch implements this, and allows my 2.6.27 i686 based
guest with 768MB of memory to boot on a RHEL-5 hypervisor again.
Thanks to Jeremy for the suggestions about how to fix this particular
issue.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-24 00:40:25 +00:00
|
|
|
pte = lookup_address(address, &level);
|
|
|
|
BUG_ON(pte == NULL);
|
|
|
|
offset = address & ~PAGE_MASK;
|
2008-07-08 22:06:54 +00:00
|
|
|
return XMADDR(((phys_addr_t)pte_mfn(*pte) << PAGE_SHIFT) + offset);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
2011-01-14 23:36:26 +00:00
|
|
|
EXPORT_SYMBOL_GPL(arbitrary_virt_to_machine);
|
2007-07-18 01:37:04 +00:00
|
|
|
|
|
|
|
void make_lowmem_page_readonly(void *vaddr)
|
|
|
|
{
|
|
|
|
pte_t *pte, ptev;
|
|
|
|
unsigned long address = (unsigned long)vaddr;
|
2008-02-09 22:24:08 +00:00
|
|
|
unsigned int level;
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2008-01-30 12:33:43 +00:00
|
|
|
pte = lookup_address(address, &level);
|
2010-10-13 23:02:24 +00:00
|
|
|
if (pte == NULL)
|
|
|
|
return; /* vaddr missing */
|
2007-07-18 01:37:04 +00:00
|
|
|
|
|
|
|
ptev = pte_wrprotect(*pte);
|
|
|
|
|
|
|
|
if (HYPERVISOR_update_va_mapping(address, ptev, 0))
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
|
|
|
void make_lowmem_page_readwrite(void *vaddr)
|
|
|
|
{
|
|
|
|
pte_t *pte, ptev;
|
|
|
|
unsigned long address = (unsigned long)vaddr;
|
2008-02-09 22:24:08 +00:00
|
|
|
unsigned int level;
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2008-01-30 12:33:43 +00:00
|
|
|
pte = lookup_address(address, &level);
|
2010-10-13 23:02:24 +00:00
|
|
|
if (pte == NULL)
|
|
|
|
return; /* vaddr missing */
|
2007-07-18 01:37:04 +00:00
|
|
|
|
|
|
|
ptev = pte_mkwrite(*pte);
|
|
|
|
|
|
|
|
if (HYPERVISOR_update_va_mapping(address, ptev, 0))
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-08-19 20:34:22 +00:00
|
|
|
static bool xen_page_pinned(void *ptr)
|
2008-05-31 00:24:27 +00:00
|
|
|
{
|
|
|
|
struct page *page = virt_to_page(ptr);
|
|
|
|
|
|
|
|
return PagePinned(page);
|
|
|
|
}
|
|
|
|
|
2009-02-09 20:05:49 +00:00
|
|
|
void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid)
|
2010-02-04 22:46:34 +00:00
|
|
|
{
|
|
|
|
struct multicall_space mcs;
|
|
|
|
struct mmu_update *u;
|
|
|
|
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_set_domain_pte(ptep, pteval, domid);
|
|
|
|
|
2010-02-04 22:46:34 +00:00
|
|
|
mcs = xen_mc_entry(sizeof(*u));
|
|
|
|
u = mcs.args;
|
|
|
|
|
|
|
|
/* ptep might be kmapped when using 32-bit HIGHPTE */
|
2010-12-22 21:09:40 +00:00
|
|
|
u->ptr = virt_to_machine(ptep).maddr;
|
2010-02-04 22:46:34 +00:00
|
|
|
u->val = pte_val_ma(pteval);
|
|
|
|
|
2009-02-09 20:05:49 +00:00
|
|
|
MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, domid);
|
2010-02-04 22:46:34 +00:00
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
|
|
|
}
|
2009-02-09 20:05:49 +00:00
|
|
|
EXPORT_SYMBOL_GPL(xen_set_domain_pte);
|
|
|
|
|
2008-08-19 20:34:22 +00:00
|
|
|
static void xen_extend_mmu_update(const struct mmu_update *update)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2007-07-18 01:37:06 +00:00
|
|
|
struct multicall_space mcs;
|
|
|
|
struct mmu_update *u;
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2008-06-16 11:30:03 +00:00
|
|
|
mcs = xen_mc_extend_args(__HYPERVISOR_mmu_update, sizeof(*u));
|
|
|
|
|
2008-08-21 00:02:19 +00:00
|
|
|
if (mcs.mc != NULL) {
|
2008-06-16 11:30:03 +00:00
|
|
|
mcs.mc->args[1]++;
|
2008-08-21 00:02:19 +00:00
|
|
|
} else {
|
2008-06-16 11:30:03 +00:00
|
|
|
mcs = __xen_mc_entry(sizeof(*u));
|
|
|
|
MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
|
|
|
|
}
|
2007-07-18 01:37:06 +00:00
|
|
|
|
|
|
|
u = mcs.args;
|
2008-06-16 11:30:03 +00:00
|
|
|
*u = *update;
|
|
|
|
}
|
|
|
|
|
2010-12-17 17:17:32 +00:00
|
|
|
static void xen_extend_mmuext_op(const struct mmuext_op *op)
|
|
|
|
{
|
|
|
|
struct multicall_space mcs;
|
|
|
|
struct mmuext_op *u;
|
|
|
|
|
|
|
|
mcs = xen_mc_extend_args(__HYPERVISOR_mmuext_op, sizeof(*u));
|
|
|
|
|
|
|
|
if (mcs.mc != NULL) {
|
|
|
|
mcs.mc->args[1]++;
|
|
|
|
} else {
|
|
|
|
mcs = __xen_mc_entry(sizeof(*u));
|
|
|
|
MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
|
|
|
|
}
|
|
|
|
|
|
|
|
u = mcs.args;
|
|
|
|
*u = *op;
|
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_set_pmd_hyper(pmd_t *ptr, pmd_t val)
|
2008-06-16 11:30:03 +00:00
|
|
|
{
|
|
|
|
struct mmu_update u;
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
|
|
|
|
xen_mc_batch();
|
|
|
|
|
2008-07-08 22:06:55 +00:00
|
|
|
/* ptr may be ioremapped for 64-bit pagetable setup */
|
|
|
|
u.ptr = arbitrary_virt_to_machine(ptr).maddr;
|
2008-06-16 11:30:03 +00:00
|
|
|
u.val = pmd_val_ma(val);
|
2008-08-19 20:34:22 +00:00
|
|
|
xen_extend_mmu_update(&u);
|
2007-07-18 01:37:06 +00:00
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
|
|
|
|
|
|
|
preempt_enable();
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_set_pmd(pmd_t *ptr, pmd_t val)
|
2008-05-31 00:24:27 +00:00
|
|
|
{
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_set_pmd(ptr, val);
|
|
|
|
|
2008-05-31 00:24:27 +00:00
|
|
|
/* If page is not pinned, we can just update the entry
|
|
|
|
directly */
|
2008-08-19 20:34:22 +00:00
|
|
|
if (!xen_page_pinned(ptr)) {
|
2008-05-31 00:24:27 +00:00
|
|
|
*ptr = val;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
xen_set_pmd_hyper(ptr, val);
|
|
|
|
}
|
|
|
|
|
2007-07-18 01:37:04 +00:00
|
|
|
/*
|
|
|
|
* Associate a virtual page frame with a given physical page frame
|
|
|
|
* and protection flags for that frame.
|
|
|
|
*/
|
|
|
|
void set_pte_mfn(unsigned long vaddr, unsigned long mfn, pgprot_t flags)
|
|
|
|
{
|
2008-07-08 22:06:58 +00:00
|
|
|
set_pte_vaddr(vaddr, mfn_pte(mfn, flags));
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2010-12-01 23:30:41 +00:00
|
|
|
static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2010-12-01 23:30:41 +00:00
|
|
|
struct mmu_update u;
|
2010-02-04 22:46:34 +00:00
|
|
|
|
2010-12-01 23:30:41 +00:00
|
|
|
if (paravirt_get_lazy_mode() != PARAVIRT_LAZY_MMU)
|
|
|
|
return false;
|
2008-08-21 00:02:19 +00:00
|
|
|
|
2010-12-01 23:30:41 +00:00
|
|
|
xen_mc_batch();
|
2007-07-18 01:37:06 +00:00
|
|
|
|
2010-12-01 23:30:41 +00:00
|
|
|
u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
|
|
|
|
u.val = pte_val_ma(pteval);
|
|
|
|
xen_extend_mmu_update(&u);
|
2010-12-01 23:13:34 +00:00
|
|
|
|
2010-12-01 23:30:41 +00:00
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
2008-04-02 17:54:10 +00:00
|
|
|
|
2010-12-01 23:30:41 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2010-12-17 01:02:35 +00:00
|
|
|
static inline void __xen_set_pte(pte_t *ptep, pte_t pteval)
|
2010-12-01 23:30:41 +00:00
|
|
|
{
|
2012-07-09 10:39:05 +00:00
|
|
|
if (!xen_batched_set_pte(ptep, pteval)) {
|
|
|
|
/*
|
|
|
|
* Could call native_set_pte() here and trap and
|
|
|
|
* emulate the PTE write but with 32-bit guests this
|
|
|
|
* needs two traps (one for each of the two 32-bit
|
|
|
|
* words in the PTE) so do one hypercall directly
|
|
|
|
* instead.
|
|
|
|
*/
|
|
|
|
struct mmu_update u;
|
|
|
|
|
|
|
|
u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
|
|
|
|
u.val = pte_val_ma(pteval);
|
|
|
|
HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF);
|
|
|
|
}
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2010-12-17 01:02:35 +00:00
|
|
|
static void xen_set_pte(pte_t *ptep, pte_t pteval)
|
|
|
|
{
|
|
|
|
trace_xen_mmu_set_pte(ptep, pteval);
|
|
|
|
__xen_set_pte(ptep, pteval);
|
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
|
2010-12-01 23:30:41 +00:00
|
|
|
pte_t *ptep, pte_t pteval)
|
|
|
|
{
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_set_pte_at(mm, addr, ptep, pteval);
|
|
|
|
__xen_set_pte(ptep, pteval);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2008-12-16 19:56:06 +00:00
|
|
|
pte_t xen_ptep_modify_prot_start(struct mm_struct *mm,
|
|
|
|
unsigned long addr, pte_t *ptep)
|
2008-03-17 23:37:09 +00:00
|
|
|
{
|
2008-06-16 11:30:02 +00:00
|
|
|
/* Just return the pte as-is. We preserve the bits on commit */
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_ptep_modify_prot_start(mm, addr, ptep, *ptep);
|
2008-06-16 11:30:02 +00:00
|
|
|
return *ptep;
|
|
|
|
}
|
|
|
|
|
|
|
|
void xen_ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr,
|
|
|
|
pte_t *ptep, pte_t pte)
|
|
|
|
{
|
2008-06-16 11:30:03 +00:00
|
|
|
struct mmu_update u;
|
2008-06-16 11:30:02 +00:00
|
|
|
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_ptep_modify_prot_commit(mm, addr, ptep, pte);
|
2008-06-16 11:30:03 +00:00
|
|
|
xen_mc_batch();
|
2008-03-17 23:37:09 +00:00
|
|
|
|
2010-12-22 21:09:40 +00:00
|
|
|
u.ptr = virt_to_machine(ptep).maddr | MMU_PT_UPDATE_PRESERVE_AD;
|
2008-06-16 11:30:03 +00:00
|
|
|
u.val = pte_val_ma(pte);
|
2008-08-19 20:34:22 +00:00
|
|
|
xen_extend_mmu_update(&u);
|
2008-03-17 23:37:09 +00:00
|
|
|
|
2008-06-16 11:30:02 +00:00
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
|
|
|
|
2008-06-16 22:01:56 +00:00
|
|
|
/* Assume pteval_t is equivalent to all the other *val_t types. */
|
|
|
|
static pteval_t pte_mfn_to_pfn(pteval_t val)
|
2008-03-17 23:37:09 +00:00
|
|
|
{
|
2008-06-16 22:01:56 +00:00
|
|
|
if (val & _PAGE_PRESENT) {
|
2008-07-22 05:59:42 +00:00
|
|
|
unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
|
2012-05-03 20:14:14 +00:00
|
|
|
unsigned long pfn = mfn_to_pfn(mfn);
|
|
|
|
|
2008-07-22 05:59:56 +00:00
|
|
|
pteval_t flags = val & PTE_FLAGS_MASK;
|
2012-05-03 20:14:14 +00:00
|
|
|
if (unlikely(pfn == ~0))
|
|
|
|
val = flags & ~_PAGE_PRESENT;
|
|
|
|
else
|
|
|
|
val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
|
2008-06-16 22:01:56 +00:00
|
|
|
}
|
2008-03-17 23:37:09 +00:00
|
|
|
|
2008-06-16 22:01:56 +00:00
|
|
|
return val;
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
|
|
|
|
2008-06-16 22:01:56 +00:00
|
|
|
static pteval_t pte_pfn_to_mfn(pteval_t val)
|
2008-03-17 23:37:09 +00:00
|
|
|
{
|
2008-06-16 22:01:56 +00:00
|
|
|
if (val & _PAGE_PRESENT) {
|
2008-07-22 05:59:42 +00:00
|
|
|
unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
|
2008-07-22 05:59:56 +00:00
|
|
|
pteval_t flags = val & PTE_FLAGS_MASK;
|
2011-01-05 20:46:31 +00:00
|
|
|
unsigned long mfn;
|
2010-08-31 21:06:22 +00:00
|
|
|
|
2011-01-05 20:46:31 +00:00
|
|
|
if (!xen_feature(XENFEAT_auto_translated_physmap))
|
|
|
|
mfn = get_phys_to_machine(pfn);
|
|
|
|
else
|
|
|
|
mfn = pfn;
|
2010-08-31 21:06:22 +00:00
|
|
|
/*
|
|
|
|
* If there's no mfn for the pfn, then just create an
|
|
|
|
* empty non-present pte. Unfortunately this loses
|
|
|
|
* information about the original pfn, so
|
|
|
|
* pte_mfn_to_pfn is asymmetric.
|
|
|
|
*/
|
|
|
|
if (unlikely(mfn == INVALID_P2M_ENTRY)) {
|
|
|
|
mfn = 0;
|
|
|
|
flags = 0;
|
2011-01-05 20:46:31 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Paramount to do this test _after_ the
|
|
|
|
* INVALID_P2M_ENTRY as INVALID_P2M_ENTRY &
|
|
|
|
* IDENTITY_FRAME_BIT resolves to true.
|
|
|
|
*/
|
|
|
|
mfn &= ~FOREIGN_FRAME_BIT;
|
|
|
|
if (mfn & IDENTITY_FRAME_BIT) {
|
|
|
|
mfn &= ~IDENTITY_FRAME_BIT;
|
|
|
|
flags |= _PAGE_IOMAP;
|
|
|
|
}
|
2010-08-31 21:06:22 +00:00
|
|
|
}
|
|
|
|
val = ((pteval_t)mfn << PAGE_SHIFT) | flags;
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
|
|
|
|
2008-06-16 22:01:56 +00:00
|
|
|
return val;
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
|
|
|
|
2010-02-04 22:46:34 +00:00
|
|
|
static pteval_t iomap_pte(pteval_t val)
|
|
|
|
{
|
|
|
|
if (val & _PAGE_PRESENT) {
|
|
|
|
unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
|
|
|
|
pteval_t flags = val & PTE_FLAGS_MASK;
|
|
|
|
|
|
|
|
/* We assume the pte frame number is a MFN, so
|
|
|
|
just use it as-is. */
|
|
|
|
val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
|
|
|
|
}
|
|
|
|
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static pteval_t xen_pte_val(pte_t pte)
|
2008-03-17 23:37:09 +00:00
|
|
|
{
|
2010-03-30 18:47:40 +00:00
|
|
|
pteval_t pteval = pte.pte;
|
2012-02-10 14:16:27 +00:00
|
|
|
#if 0
|
2010-03-30 18:47:40 +00:00
|
|
|
/* If this is a WC pte, convert back from Xen WC to Linux WC */
|
|
|
|
if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
|
|
|
|
WARN_ON(!pat_enabled);
|
|
|
|
pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
|
|
|
|
}
|
2012-02-10 14:16:27 +00:00
|
|
|
#endif
|
2010-03-30 18:47:40 +00:00
|
|
|
if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
|
|
|
|
return pteval;
|
|
|
|
|
|
|
|
return pte_mfn_to_pfn(pteval);
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
2009-01-28 22:35:07 +00:00
|
|
|
PV_CALLEE_SAVE_REGS_THUNK(xen_pte_val);
|
2008-03-17 23:37:09 +00:00
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static pgdval_t xen_pgd_val(pgd_t pgd)
|
2008-03-17 23:37:09 +00:00
|
|
|
{
|
2008-06-16 22:01:56 +00:00
|
|
|
return pte_mfn_to_pfn(pgd.pgd);
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
2009-01-28 22:35:07 +00:00
|
|
|
PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);
|
2008-03-17 23:37:09 +00:00
|
|
|
|
2010-03-30 18:47:40 +00:00
|
|
|
/*
|
|
|
|
* Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
|
|
|
|
* are reserved for now, to correspond to the Intel-reserved PAT
|
|
|
|
* types.
|
|
|
|
*
|
|
|
|
* We expect Linux's PAT set as follows:
|
|
|
|
*
|
|
|
|
* Idx PTE flags Linux Xen Default
|
|
|
|
* 0 WB WB WB
|
|
|
|
* 1 PWT WC WT WT
|
|
|
|
* 2 PCD UC- UC- UC-
|
|
|
|
* 3 PCD PWT UC UC UC
|
|
|
|
* 4 PAT WB WC WB
|
|
|
|
* 5 PAT PWT WC WP WT
|
|
|
|
* 6 PAT PCD UC- UC UC-
|
|
|
|
* 7 PAT PCD PWT UC UC UC
|
|
|
|
*/
|
|
|
|
|
|
|
|
void xen_set_pat(u64 pat)
|
|
|
|
{
|
|
|
|
/* We expect Linux to use a PAT setting of
|
|
|
|
* UC UC- WC WB (ignoring the PAT flag) */
|
|
|
|
WARN_ON(pat != 0x0007010600070106ull);
|
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static pte_t xen_make_pte(pteval_t pte)
|
2008-03-17 23:37:09 +00:00
|
|
|
{
|
2010-02-19 18:31:06 +00:00
|
|
|
phys_addr_t addr = (pte & PTE_PFN_MASK);
|
2012-02-10 14:16:27 +00:00
|
|
|
#if 0
|
2010-03-30 18:47:40 +00:00
|
|
|
/* If Linux is trying to set a WC pte, then map to the Xen WC.
|
|
|
|
* If _PAGE_PAT is set, then it probably means it is really
|
|
|
|
* _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
|
|
|
|
* things work out OK...
|
|
|
|
*
|
|
|
|
* (We should never see kernel mappings with _PAGE_PSE set,
|
|
|
|
* but we could see hugetlbfs mappings, I think.).
|
|
|
|
*/
|
|
|
|
if (pat_enabled && !WARN_ON(pte & _PAGE_PAT)) {
|
|
|
|
if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
|
|
|
|
pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
|
|
|
|
}
|
2012-02-10 14:16:27 +00:00
|
|
|
#endif
|
2010-02-19 18:31:06 +00:00
|
|
|
/*
|
|
|
|
* Unprivileged domains are allowed to do IOMAPpings for
|
|
|
|
* PCI passthrough, but not map ISA space. The ISA
|
|
|
|
* mappings are just dummy local mappings to keep other
|
|
|
|
* parts of the kernel happy.
|
|
|
|
*/
|
|
|
|
if (unlikely(pte & _PAGE_IOMAP) &&
|
|
|
|
(xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
|
2010-02-04 22:46:34 +00:00
|
|
|
pte = iomap_pte(pte);
|
2010-02-19 18:31:06 +00:00
|
|
|
} else {
|
|
|
|
pte &= ~_PAGE_IOMAP;
|
2010-02-04 22:46:34 +00:00
|
|
|
pte = pte_pfn_to_mfn(pte);
|
2010-02-19 18:31:06 +00:00
|
|
|
}
|
2010-02-04 22:46:34 +00:00
|
|
|
|
2008-06-16 22:01:56 +00:00
|
|
|
return native_make_pte(pte);
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
2009-01-28 22:35:07 +00:00
|
|
|
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte);
|
2008-03-17 23:37:09 +00:00
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static pgd_t xen_make_pgd(pgdval_t pgd)
|
2008-03-17 23:37:09 +00:00
|
|
|
{
|
2008-06-16 22:01:56 +00:00
|
|
|
pgd = pte_pfn_to_mfn(pgd);
|
|
|
|
return native_make_pgd(pgd);
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
2009-01-28 22:35:07 +00:00
|
|
|
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pgd);
|
2008-03-17 23:37:09 +00:00
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static pmdval_t xen_pmd_val(pmd_t pmd)
|
2008-03-17 23:37:09 +00:00
|
|
|
{
|
2008-06-16 22:01:56 +00:00
|
|
|
return pte_mfn_to_pfn(pmd.pmd);
|
2008-03-17 23:37:09 +00:00
|
|
|
}
|
2009-01-28 22:35:07 +00:00
|
|
|
PV_CALLEE_SAVE_REGS_THUNK(xen_pmd_val);
|
2008-05-09 11:05:57 +00:00
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_set_pud_hyper(pud_t *ptr, pud_t val)
|
2007-07-18 01:37:05 +00:00
|
|
|
{
|
2008-06-16 11:30:03 +00:00
|
|
|
struct mmu_update u;
|
2007-07-18 01:37:05 +00:00
|
|
|
|
2007-07-18 01:37:06 +00:00
|
|
|
preempt_disable();
|
|
|
|
|
2008-06-16 11:30:03 +00:00
|
|
|
xen_mc_batch();
|
|
|
|
|
2008-07-08 22:06:55 +00:00
|
|
|
/* ptr may be ioremapped for 64-bit pagetable setup */
|
|
|
|
u.ptr = arbitrary_virt_to_machine(ptr).maddr;
|
2008-06-16 11:30:03 +00:00
|
|
|
u.val = pud_val_ma(val);
|
2008-08-19 20:34:22 +00:00
|
|
|
xen_extend_mmu_update(&u);
|
2007-07-18 01:37:06 +00:00
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
|
|
|
|
|
|
|
preempt_enable();
|
2007-07-18 01:37:05 +00:00
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_set_pud(pud_t *ptr, pud_t val)
|
2008-05-31 00:24:27 +00:00
|
|
|
{
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_set_pud(ptr, val);
|
|
|
|
|
2008-05-31 00:24:27 +00:00
|
|
|
/* If page is not pinned, we can just update the entry
|
|
|
|
directly */
|
2008-08-19 20:34:22 +00:00
|
|
|
if (!xen_page_pinned(ptr)) {
|
2008-05-31 00:24:27 +00:00
|
|
|
*ptr = val;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
xen_set_pud_hyper(ptr, val);
|
|
|
|
}
|
|
|
|
|
2008-07-08 22:06:38 +00:00
|
|
|
#ifdef CONFIG_X86_PAE
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_set_pte_atomic(ptep, pte);
|
2008-07-08 22:06:38 +00:00
|
|
|
set_64bit((u64 *)ptep, native_pte_val(pte));
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_pte_clear(mm, addr, ptep);
|
2010-12-01 23:30:41 +00:00
|
|
|
if (!xen_batched_set_pte(ptep, native_make_pte(0)))
|
|
|
|
native_pte_clear(mm, addr, ptep);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_pmd_clear(pmd_t *pmdp)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_pmd_clear(pmdp);
|
2008-05-31 00:24:27 +00:00
|
|
|
set_pmd(pmdp, __pmd(0));
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
2008-07-08 22:06:38 +00:00
|
|
|
#endif /* CONFIG_X86_PAE */
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static pmd_t xen_make_pmd(pmdval_t pmd)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2008-06-16 22:01:56 +00:00
|
|
|
pmd = pte_pfn_to_mfn(pmd);
|
2008-03-17 23:37:09 +00:00
|
|
|
return native_make_pmd(pmd);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
2009-01-28 22:35:07 +00:00
|
|
|
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pmd);
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2008-07-08 22:06:38 +00:00
|
|
|
#if PAGETABLE_LEVELS == 4
|
2010-12-02 06:57:39 +00:00
|
|
|
static pudval_t xen_pud_val(pud_t pud)
|
2008-07-08 22:06:38 +00:00
|
|
|
{
|
|
|
|
return pte_mfn_to_pfn(pud.pud);
|
|
|
|
}
|
2009-01-28 22:35:07 +00:00
|
|
|
PV_CALLEE_SAVE_REGS_THUNK(xen_pud_val);
|
2008-07-08 22:06:38 +00:00
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static pud_t xen_make_pud(pudval_t pud)
|
2008-07-08 22:06:38 +00:00
|
|
|
{
|
|
|
|
pud = pte_pfn_to_mfn(pud);
|
|
|
|
|
|
|
|
return native_make_pud(pud);
|
|
|
|
}
|
2009-01-28 22:35:07 +00:00
|
|
|
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pud);
|
2008-07-08 22:06:38 +00:00
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static pgd_t *xen_get_user_pgd(pgd_t *pgd)
|
2008-07-08 22:06:38 +00:00
|
|
|
{
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
pgd_t *pgd_page = (pgd_t *)(((unsigned long)pgd) & PAGE_MASK);
|
|
|
|
unsigned offset = pgd - pgd_page;
|
|
|
|
pgd_t *user_ptr = NULL;
|
2008-07-08 22:06:38 +00:00
|
|
|
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
if (offset < pgd_index(USER_LIMIT)) {
|
|
|
|
struct page *page = virt_to_page(pgd_page);
|
|
|
|
user_ptr = (pgd_t *)page->private;
|
|
|
|
if (user_ptr)
|
|
|
|
user_ptr += offset;
|
|
|
|
}
|
2008-07-08 22:06:38 +00:00
|
|
|
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
return user_ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
|
|
|
|
{
|
|
|
|
struct mmu_update u;
|
2008-07-08 22:06:38 +00:00
|
|
|
|
|
|
|
u.ptr = virt_to_machine(ptr).maddr;
|
|
|
|
u.val = pgd_val_ma(val);
|
2008-08-19 20:34:22 +00:00
|
|
|
xen_extend_mmu_update(&u);
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Raw hypercall-based set_pgd, intended for in early boot before
|
|
|
|
* there's a page structure. This implies:
|
|
|
|
* 1. The only existing pagetable is the kernel's
|
|
|
|
* 2. It is always pinned
|
|
|
|
* 3. It has no user pagetable attached to it
|
|
|
|
*/
|
2010-12-02 06:57:39 +00:00
|
|
|
static void __init xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
{
|
|
|
|
preempt_disable();
|
|
|
|
|
|
|
|
xen_mc_batch();
|
|
|
|
|
|
|
|
__xen_set_pgd_hyper(ptr, val);
|
2008-07-08 22:06:38 +00:00
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
|
|
|
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_set_pgd(pgd_t *ptr, pgd_t val)
|
2008-07-08 22:06:38 +00:00
|
|
|
{
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
pgd_t *user_ptr = xen_get_user_pgd(ptr);
|
|
|
|
|
2010-12-17 01:02:35 +00:00
|
|
|
trace_xen_mmu_set_pgd(ptr, user_ptr, val);
|
|
|
|
|
2008-07-08 22:06:38 +00:00
|
|
|
/* If page is not pinned, we can just update the entry
|
|
|
|
directly */
|
2008-08-19 20:34:22 +00:00
|
|
|
if (!xen_page_pinned(ptr)) {
|
2008-07-08 22:06:38 +00:00
|
|
|
*ptr = val;
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
if (user_ptr) {
|
2008-08-19 20:34:22 +00:00
|
|
|
WARN_ON(xen_page_pinned(user_ptr));
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
*user_ptr = val;
|
|
|
|
}
|
2008-07-08 22:06:38 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
/* If it's pinned, then we can at least batch the kernel and
|
|
|
|
user updates together. */
|
|
|
|
xen_mc_batch();
|
|
|
|
|
|
|
|
__xen_set_pgd_hyper(ptr, val);
|
|
|
|
if (user_ptr)
|
|
|
|
__xen_set_pgd_hyper(user_ptr, val);
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
2008-07-08 22:06:38 +00:00
|
|
|
}
|
|
|
|
#endif /* PAGETABLE_LEVELS == 4 */
|
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
/*
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
* (Yet another) pagetable walker. This one is intended for pinning a
|
|
|
|
* pagetable. This means that it walks a pagetable and calls the
|
|
|
|
* callback function on each page it finds making up the page table,
|
|
|
|
* at every level. It walks the entire pagetable, but it only bothers
|
|
|
|
* pinning pte pages which are below limit. In the normal case this
|
|
|
|
* will be STACK_TOP_MAX, but at boot we need to pin up to
|
|
|
|
* FIXADDR_TOP.
|
|
|
|
*
|
|
|
|
* For 32-bit the important bit is that we don't pin beyond there,
|
|
|
|
* because then we start getting into Xen's ptes.
|
|
|
|
*
|
|
|
|
* For 64-bit, we must skip the Xen hole in the middle of the address
|
|
|
|
* space, just after the big x86-64 virtual hole.
|
|
|
|
*/
|
2008-11-21 10:21:33 +00:00
|
|
|
static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
|
|
|
|
int (*func)(struct mm_struct *mm, struct page *,
|
|
|
|
enum pt_level),
|
|
|
|
unsigned long limit)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2007-07-18 01:37:05 +00:00
|
|
|
int flush = 0;
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
unsigned hole_low, hole_high;
|
|
|
|
unsigned pgdidx_limit, pudidx_limit, pmdidx_limit;
|
|
|
|
unsigned pgdidx, pudidx, pmdidx;
|
2007-07-18 01:37:05 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
/* The limit is the last byte to be touched */
|
|
|
|
limit--;
|
|
|
|
BUG_ON(limit >= FIXADDR_TOP);
|
2007-07-18 01:37:04 +00:00
|
|
|
|
|
|
|
if (xen_feature(XENFEAT_auto_translated_physmap))
|
2007-07-18 01:37:05 +00:00
|
|
|
return 0;
|
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
/*
|
|
|
|
* 64-bit has a great big hole in the middle of the address
|
|
|
|
* space, which contains the Xen mappings. On 32-bit these
|
|
|
|
* will end up making a zero-sized hole and so is a no-op.
|
|
|
|
*/
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
hole_low = pgd_index(USER_LIMIT);
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
hole_high = pgd_index(PAGE_OFFSET);
|
|
|
|
|
|
|
|
pgdidx_limit = pgd_index(limit);
|
|
|
|
#if PTRS_PER_PUD > 1
|
|
|
|
pudidx_limit = pud_index(limit);
|
|
|
|
#else
|
|
|
|
pudidx_limit = 0;
|
|
|
|
#endif
|
|
|
|
#if PTRS_PER_PMD > 1
|
|
|
|
pmdidx_limit = pmd_index(limit);
|
|
|
|
#else
|
|
|
|
pmdidx_limit = 0;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
for (pgdidx = 0; pgdidx <= pgdidx_limit; pgdidx++) {
|
2007-07-18 01:37:05 +00:00
|
|
|
pud_t *pud;
|
2007-07-18 01:37:04 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
if (pgdidx >= hole_low && pgdidx < hole_high)
|
|
|
|
continue;
|
2007-07-18 01:37:05 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
if (!pgd_val(pgd[pgdidx]))
|
2007-07-18 01:37:04 +00:00
|
|
|
continue;
|
2007-07-18 01:37:05 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
pud = pud_offset(&pgd[pgdidx], 0);
|
2007-07-18 01:37:04 +00:00
|
|
|
|
|
|
|
if (PTRS_PER_PUD > 1) /* not folded */
|
2008-10-08 20:01:39 +00:00
|
|
|
flush |= (*func)(mm, virt_to_page(pud), PT_PUD);
|
2007-07-18 01:37:05 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
for (pudidx = 0; pudidx < PTRS_PER_PUD; pudidx++) {
|
2007-07-18 01:37:05 +00:00
|
|
|
pmd_t *pmd;
|
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
if (pgdidx == pgdidx_limit &&
|
|
|
|
pudidx > pudidx_limit)
|
|
|
|
goto out;
|
2007-07-18 01:37:04 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
if (pud_none(pud[pudidx]))
|
2007-07-18 01:37:04 +00:00
|
|
|
continue;
|
2007-07-18 01:37:05 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
pmd = pmd_offset(&pud[pudidx], 0);
|
2007-07-18 01:37:04 +00:00
|
|
|
|
|
|
|
if (PTRS_PER_PMD > 1) /* not folded */
|
2008-10-08 20:01:39 +00:00
|
|
|
flush |= (*func)(mm, virt_to_page(pmd), PT_PMD);
|
2007-07-18 01:37:05 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
for (pmdidx = 0; pmdidx < PTRS_PER_PMD; pmdidx++) {
|
|
|
|
struct page *pte;
|
|
|
|
|
|
|
|
if (pgdidx == pgdidx_limit &&
|
|
|
|
pudidx == pudidx_limit &&
|
|
|
|
pmdidx > pmdidx_limit)
|
|
|
|
goto out;
|
2007-07-18 01:37:04 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
if (pmd_none(pmd[pmdidx]))
|
2007-07-18 01:37:04 +00:00
|
|
|
continue;
|
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
pte = pmd_page(pmd[pmdidx]);
|
2008-10-08 20:01:39 +00:00
|
|
|
flush |= (*func)(mm, pte, PT_PTE);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2008-08-19 20:32:51 +00:00
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
out:
|
2008-08-19 20:32:51 +00:00
|
|
|
/* Do the top level last, so that the callbacks can use it as
|
|
|
|
a cue to do final things like tlb flushes. */
|
2008-10-08 20:01:39 +00:00
|
|
|
flush |= (*func)(mm, virt_to_page(pgd), PT_PGD);
|
2007-07-18 01:37:05 +00:00
|
|
|
|
|
|
|
return flush;
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2008-11-21 10:21:33 +00:00
|
|
|
static int xen_pgd_walk(struct mm_struct *mm,
|
|
|
|
int (*func)(struct mm_struct *mm, struct page *,
|
|
|
|
enum pt_level),
|
|
|
|
unsigned long limit)
|
|
|
|
{
|
|
|
|
return __xen_pgd_walk(mm, mm->pgd, func, limit);
|
|
|
|
}
|
|
|
|
|
2008-08-19 20:34:22 +00:00
|
|
|
/* If we're using split pte locks, then take the page's lock and
|
|
|
|
return a pointer to it. Otherwise return NULL. */
|
2008-10-08 20:01:39 +00:00
|
|
|
static spinlock_t *xen_pte_lock(struct page *page, struct mm_struct *mm)
|
2007-10-16 18:51:30 +00:00
|
|
|
{
|
|
|
|
spinlock_t *ptl = NULL;
|
|
|
|
|
2008-09-09 22:43:22 +00:00
|
|
|
#if USE_SPLIT_PTLOCKS
|
2007-10-16 18:51:30 +00:00
|
|
|
ptl = __pte_lockptr(page);
|
2008-10-08 20:01:39 +00:00
|
|
|
spin_lock_nest_lock(ptl, &mm->page_table_lock);
|
2007-10-16 18:51:30 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
return ptl;
|
|
|
|
}
|
|
|
|
|
2008-08-19 20:34:22 +00:00
|
|
|
static void xen_pte_unlock(void *v)
|
2007-10-16 18:51:30 +00:00
|
|
|
{
|
|
|
|
spinlock_t *ptl = v;
|
|
|
|
spin_unlock(ptl);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_do_pin(unsigned level, unsigned long pfn)
|
|
|
|
{
|
2010-12-17 17:17:32 +00:00
|
|
|
struct mmuext_op op;
|
2007-10-16 18:51:30 +00:00
|
|
|
|
2010-12-17 17:17:32 +00:00
|
|
|
op.cmd = level;
|
|
|
|
op.arg1.mfn = pfn_to_mfn(pfn);
|
|
|
|
|
|
|
|
xen_extend_mmuext_op(&op);
|
2007-10-16 18:51:30 +00:00
|
|
|
}
|
|
|
|
|
2008-10-08 20:01:39 +00:00
|
|
|
static int xen_pin_page(struct mm_struct *mm, struct page *page,
|
|
|
|
enum pt_level level)
|
2007-07-18 01:37:05 +00:00
|
|
|
{
|
2008-04-28 09:12:51 +00:00
|
|
|
unsigned pgfl = TestSetPagePinned(page);
|
2007-07-18 01:37:05 +00:00
|
|
|
int flush;
|
|
|
|
|
|
|
|
if (pgfl)
|
|
|
|
flush = 0; /* already pinned */
|
|
|
|
else if (PageHighMem(page))
|
|
|
|
/* kmaps need flushing if we found an unpinned
|
|
|
|
highpage */
|
|
|
|
flush = 1;
|
|
|
|
else {
|
|
|
|
void *pt = lowmem_page_address(page);
|
|
|
|
unsigned long pfn = page_to_pfn(page);
|
|
|
|
struct multicall_space mcs = __xen_mc_entry(0);
|
2007-10-16 18:51:30 +00:00
|
|
|
spinlock_t *ptl;
|
2007-07-18 01:37:05 +00:00
|
|
|
|
|
|
|
flush = 0;
|
|
|
|
|
2008-08-19 20:32:51 +00:00
|
|
|
/*
|
|
|
|
* We need to hold the pagetable lock between the time
|
|
|
|
* we make the pagetable RO and when we actually pin
|
|
|
|
* it. If we don't, then other users may come in and
|
|
|
|
* attempt to update the pagetable by writing it,
|
|
|
|
* which will fail because the memory is RO but not
|
|
|
|
* pinned, so Xen won't do the trap'n'emulate.
|
|
|
|
*
|
|
|
|
* If we're using split pte locks, we can't hold the
|
|
|
|
* entire pagetable's worth of locks during the
|
|
|
|
* traverse, because we may wrap the preempt count (8
|
|
|
|
* bits). The solution is to mark RO and pin each PTE
|
|
|
|
* page while holding the lock. This means the number
|
|
|
|
* of locks we end up holding is never more than a
|
|
|
|
* batch size (~32 entries, at present).
|
|
|
|
*
|
|
|
|
* If we're not using split pte locks, we needn't pin
|
|
|
|
* the PTE pages independently, because we're
|
|
|
|
* protected by the overall pagetable lock.
|
|
|
|
*/
|
2007-10-16 18:51:30 +00:00
|
|
|
ptl = NULL;
|
|
|
|
if (level == PT_PTE)
|
2008-10-08 20:01:39 +00:00
|
|
|
ptl = xen_pte_lock(page, mm);
|
2007-10-16 18:51:30 +00:00
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
|
|
|
|
pfn_pte(pfn, PAGE_KERNEL_RO),
|
2007-10-16 18:51:30 +00:00
|
|
|
level == PT_PGD ? UVMF_TLB_FLUSH : 0);
|
|
|
|
|
2008-08-19 20:32:51 +00:00
|
|
|
if (ptl) {
|
2007-10-16 18:51:30 +00:00
|
|
|
xen_do_pin(MMUEXT_PIN_L1_TABLE, pfn);
|
|
|
|
|
|
|
|
/* Queue a deferred unlock for when this batch
|
|
|
|
is completed. */
|
2008-08-19 20:34:22 +00:00
|
|
|
xen_mc_callback(xen_pte_unlock, ptl);
|
2007-10-16 18:51:30 +00:00
|
|
|
}
|
2007-07-18 01:37:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return flush;
|
|
|
|
}
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
/* This is called just after a mm has been created, but it has not
|
|
|
|
been used yet. We need to make sure that its pagetable is all
|
|
|
|
read-only, and can be pinned. */
|
2008-10-08 20:01:39 +00:00
|
|
|
static void __xen_pgd_pin(struct mm_struct *mm, pgd_t *pgd)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2010-12-17 23:31:23 +00:00
|
|
|
trace_xen_mmu_pgd_pin(mm, pgd);
|
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
xen_mc_batch();
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2008-11-21 10:21:33 +00:00
|
|
|
if (__xen_pgd_walk(mm, pgd, xen_pin_page, USER_LIMIT)) {
|
2008-10-28 08:23:06 +00:00
|
|
|
/* re-enable interrupts for flushing */
|
2007-07-18 01:37:06 +00:00
|
|
|
xen_mc_issue(0);
|
2008-10-28 08:23:06 +00:00
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
kmap_flush_unused();
|
2008-10-28 08:23:06 +00:00
|
|
|
|
2007-07-18 01:37:06 +00:00
|
|
|
xen_mc_batch();
|
|
|
|
}
|
2007-07-18 01:37:05 +00:00
|
|
|
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
{
|
|
|
|
pgd_t *user_pgd = xen_get_user_pgd(pgd);
|
|
|
|
|
|
|
|
xen_do_pin(MMUEXT_PIN_L4_TABLE, PFN_DOWN(__pa(pgd)));
|
|
|
|
|
|
|
|
if (user_pgd) {
|
2008-10-08 20:01:39 +00:00
|
|
|
xen_pin_page(mm, virt_to_page(user_pgd), PT_PGD);
|
2008-12-16 19:56:06 +00:00
|
|
|
xen_do_pin(MMUEXT_PIN_L4_TABLE,
|
|
|
|
PFN_DOWN(__pa(user_pgd)));
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#else /* CONFIG_X86_32 */
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
#ifdef CONFIG_X86_PAE
|
|
|
|
/* Need to make sure unshared kernel PMD is pinnable */
|
2008-11-06 21:48:24 +00:00
|
|
|
xen_pin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
|
2008-10-08 20:01:39 +00:00
|
|
|
PT_PMD);
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
#endif
|
2008-05-09 11:05:57 +00:00
|
|
|
xen_do_pin(MMUEXT_PIN_L3_TABLE, PFN_DOWN(__pa(pgd)));
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
#endif /* CONFIG_X86_64 */
|
2007-07-18 01:37:05 +00:00
|
|
|
xen_mc_issue(0);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2008-10-08 20:01:39 +00:00
|
|
|
static void xen_pgd_pin(struct mm_struct *mm)
|
|
|
|
{
|
|
|
|
__xen_pgd_pin(mm, mm->pgd);
|
|
|
|
}
|
|
|
|
|
2008-05-26 22:31:27 +00:00
|
|
|
/*
|
|
|
|
* On save, we need to pin all pagetables to make sure they get their
|
|
|
|
* mfns turned into pfns. Search the list for any unpinned pgds and pin
|
|
|
|
* them (unpinned pgds are not currently in use, probably because the
|
|
|
|
* process is under construction or destruction).
|
2008-10-08 20:01:39 +00:00
|
|
|
*
|
|
|
|
* Expected to be called in stop_machine() ("equivalent to taking
|
|
|
|
* every spinlock in the system"), so the locking doesn't really
|
|
|
|
* matter all that much.
|
2008-05-26 22:31:27 +00:00
|
|
|
*/
|
|
|
|
void xen_mm_pin_all(void)
|
|
|
|
{
|
|
|
|
struct page *page;
|
2007-10-16 18:51:30 +00:00
|
|
|
|
2011-02-16 23:45:22 +00:00
|
|
|
spin_lock(&pgd_lock);
|
2007-07-18 01:37:05 +00:00
|
|
|
|
2008-05-26 22:31:27 +00:00
|
|
|
list_for_each_entry(page, &pgd_list, lru) {
|
|
|
|
if (!PagePinned(page)) {
|
2008-10-08 20:01:39 +00:00
|
|
|
__xen_pgd_pin(&init_mm, (pgd_t *)page_address(page));
|
2008-05-26 22:31:27 +00:00
|
|
|
SetPageSavePinned(page);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-02-16 23:45:22 +00:00
|
|
|
spin_unlock(&pgd_lock);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2008-07-08 22:06:24 +00:00
|
|
|
/*
|
|
|
|
* The init_mm pagetable is really pinned as soon as its created, but
|
|
|
|
* that's before we have page structures to store the bits. So do all
|
|
|
|
* the book-keeping now.
|
|
|
|
*/
|
2011-05-12 21:19:53 +00:00
|
|
|
static int __init xen_mark_pinned(struct mm_struct *mm, struct page *page,
|
2008-10-08 20:01:39 +00:00
|
|
|
enum pt_level level)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2007-07-18 01:37:05 +00:00
|
|
|
SetPagePinned(page);
|
|
|
|
return 0;
|
|
|
|
}
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2009-03-17 20:30:55 +00:00
|
|
|
static void __init xen_mark_init_mm_pinned(void)
|
2007-07-18 01:37:05 +00:00
|
|
|
{
|
2008-10-08 20:01:39 +00:00
|
|
|
xen_pgd_walk(&init_mm, xen_mark_pinned, FIXADDR_TOP);
|
2007-07-18 01:37:05 +00:00
|
|
|
}
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2008-10-08 20:01:39 +00:00
|
|
|
static int xen_unpin_page(struct mm_struct *mm, struct page *page,
|
|
|
|
enum pt_level level)
|
2007-07-18 01:37:05 +00:00
|
|
|
{
|
2008-04-28 09:12:51 +00:00
|
|
|
unsigned pgfl = TestClearPagePinned(page);
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
if (pgfl && !PageHighMem(page)) {
|
|
|
|
void *pt = lowmem_page_address(page);
|
|
|
|
unsigned long pfn = page_to_pfn(page);
|
2007-10-16 18:51:30 +00:00
|
|
|
spinlock_t *ptl = NULL;
|
|
|
|
struct multicall_space mcs;
|
|
|
|
|
2008-08-19 20:32:51 +00:00
|
|
|
/*
|
|
|
|
* Do the converse to pin_page. If we're using split
|
|
|
|
* pte locks, we must be holding the lock for while
|
|
|
|
* the pte page is unpinned but still RO to prevent
|
|
|
|
* concurrent updates from seeing it in this
|
|
|
|
* partially-pinned state.
|
|
|
|
*/
|
2007-10-16 18:51:30 +00:00
|
|
|
if (level == PT_PTE) {
|
2008-10-08 20:01:39 +00:00
|
|
|
ptl = xen_pte_lock(page, mm);
|
2007-10-16 18:51:30 +00:00
|
|
|
|
2008-08-19 20:32:51 +00:00
|
|
|
if (ptl)
|
|
|
|
xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
|
2007-10-16 18:51:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
mcs = __xen_mc_entry(0);
|
2007-07-18 01:37:05 +00:00
|
|
|
|
|
|
|
MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
|
|
|
|
pfn_pte(pfn, PAGE_KERNEL),
|
2007-10-16 18:51:30 +00:00
|
|
|
level == PT_PGD ? UVMF_TLB_FLUSH : 0);
|
|
|
|
|
|
|
|
if (ptl) {
|
|
|
|
/* unlock when batch completed */
|
2008-08-19 20:34:22 +00:00
|
|
|
xen_mc_callback(xen_pte_unlock, ptl);
|
2007-10-16 18:51:30 +00:00
|
|
|
}
|
2007-07-18 01:37:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0; /* never need to flush on unpin */
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
/* Release a pagetables pages back as normal RW */
|
2008-10-08 20:01:39 +00:00
|
|
|
static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
|
2007-07-18 01:37:05 +00:00
|
|
|
{
|
2010-12-17 23:31:23 +00:00
|
|
|
trace_xen_mmu_pgd_unpin(mm, pgd);
|
|
|
|
|
2007-07-18 01:37:05 +00:00
|
|
|
xen_mc_batch();
|
|
|
|
|
2007-10-16 18:51:30 +00:00
|
|
|
xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
|
2007-07-18 01:37:05 +00:00
|
|
|
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
{
|
|
|
|
pgd_t *user_pgd = xen_get_user_pgd(pgd);
|
|
|
|
|
|
|
|
if (user_pgd) {
|
2008-12-16 19:56:06 +00:00
|
|
|
xen_do_pin(MMUEXT_UNPIN_TABLE,
|
|
|
|
PFN_DOWN(__pa(user_pgd)));
|
2008-10-08 20:01:39 +00:00
|
|
|
xen_unpin_page(mm, virt_to_page(user_pgd), PT_PGD);
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
#ifdef CONFIG_X86_PAE
|
|
|
|
/* Need to make sure unshared kernel PMD is unpinned */
|
2008-11-06 21:48:24 +00:00
|
|
|
xen_unpin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
|
2008-10-08 20:01:39 +00:00
|
|
|
PT_PMD);
|
xen: rework pgd_walk to deal with 32/64 bit
Rewrite pgd_walk to deal with 64-bit address spaces. There are two
notible features of 64-bit workspaces:
1. The physical address is only 48 bits wide, with the upper 16 bits
being sign extension; kernel addresses are negative, and userspace is
positive.
2. The Xen hypervisor mapping is at the negative-most address, just above
the sign-extension hole.
1. means that we can't easily use addresses when traversing the space,
since we must deal with sign extension. This rewrite expresses
everything in terms of pgd/pud/pmd indices, which means we don't need
to worry about the exact configuration of the virtual memory space.
This approach works equally well in 32-bit.
To deal with 2, assume the hole is between the uppermost userspace
address and PAGE_OFFSET. For 64-bit this skips the Xen mapping hole.
For 32-bit, the hole is zero-sized.
In all cases, the uppermost kernel address is FIXADDR_TOP.
A side-effect of this patch is that the upper boundary is actually
handled properly, exposing a long-standing bug in 32-bit, which failed
to pin kernel pmd page. The kernel pmd is not shared, and so must be
explicitly pinned, even though the kernel ptes are shared and don't
need pinning.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:06 +00:00
|
|
|
#endif
|
xen64: allocate and manage user pagetables
Because the x86_64 architecture does not enforce segment limits, Xen
cannot protect itself with them as it does in 32-bit mode. Therefore,
to protect itself, it runs the guest kernel in ring 3. Since it also
runs the guest userspace in ring3, the guest kernel must maintain a
second pagetable for its userspace, which does not map kernel space.
Naturally, the guest kernel pagetables map both kernel and userspace.
The userspace pagetable is attached to the corresponding kernel
pagetable via the pgd's page->private field. It is allocated and
freed at the same time as the kernel pgd via the
paravirt_pgd_alloc/free hooks.
Fortunately, the user pagetable is almost entirely shared with the
kernel pagetable; the only difference is the pgd page itself. set_pgd
will populate all entries in the kernel pagetable, and also set the
corresponding user pgd entry if the address is less than
STACK_TOP_MAX.
The user pagetable must be pinned and unpinned with the kernel one,
but because the pagetables are aliased, pgd_walk() only needs to be
called on the kernel pagetable. The user pgd page is then
pinned/unpinned along with the kernel pgd page.
xen_write_cr3 must write both the kernel and user cr3s.
The init_mm.pgd pagetable never has a user pagetable allocated for it,
because it can never be used while running usermode.
One awkward area is that early in boot the page structures are not
available. No user pagetable can exist at that point, but it
complicates the logic to avoid looking at the page structure.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stephen Tweedie <sct@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08 22:07:13 +00:00
|
|
|
|
2008-11-21 10:21:33 +00:00
|
|
|
__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);
|
2007-07-18 01:37:05 +00:00
|
|
|
|
|
|
|
xen_mc_issue(0);
|
|
|
|
}
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2008-10-08 20:01:39 +00:00
|
|
|
static void xen_pgd_unpin(struct mm_struct *mm)
|
|
|
|
{
|
|
|
|
__xen_pgd_unpin(mm, mm->pgd);
|
|
|
|
}
|
|
|
|
|
2008-05-26 22:31:27 +00:00
|
|
|
/*
|
|
|
|
* On resume, undo any pinning done at save, so that the rest of the
|
|
|
|
* kernel doesn't see any unexpected pinned pagetables.
|
|
|
|
*/
|
|
|
|
void xen_mm_unpin_all(void)
|
|
|
|
{
|
|
|
|
struct page *page;
|
|
|
|
|
2011-02-16 23:45:22 +00:00
|
|
|
spin_lock(&pgd_lock);
|
2008-05-26 22:31:27 +00:00
|
|
|
|
|
|
|
list_for_each_entry(page, &pgd_list, lru) {
|
|
|
|
if (PageSavePinned(page)) {
|
|
|
|
BUG_ON(!PagePinned(page));
|
2008-10-08 20:01:39 +00:00
|
|
|
__xen_pgd_unpin(&init_mm, (pgd_t *)page_address(page));
|
2008-05-26 22:31:27 +00:00
|
|
|
ClearPageSavePinned(page);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-02-16 23:45:22 +00:00
|
|
|
spin_unlock(&pgd_lock);
|
2008-05-26 22:31:27 +00:00
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_activate_mm(struct mm_struct *prev, struct mm_struct *next)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2007-07-18 01:37:05 +00:00
|
|
|
spin_lock(&next->page_table_lock);
|
2008-10-08 20:01:39 +00:00
|
|
|
xen_pgd_pin(next);
|
2007-07-18 01:37:05 +00:00
|
|
|
spin_unlock(&next->page_table_lock);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm)
|
2007-07-18 01:37:04 +00:00
|
|
|
{
|
2007-07-18 01:37:05 +00:00
|
|
|
spin_lock(&mm->page_table_lock);
|
2008-10-08 20:01:39 +00:00
|
|
|
xen_pgd_pin(mm);
|
2007-07-18 01:37:05 +00:00
|
|
|
spin_unlock(&mm->page_table_lock);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-07-18 01:37:06 +00:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
/* Another cpu may still have their %cr3 pointing at the pagetable, so
|
|
|
|
we need to repoint it somewhere else before we can unpin it. */
|
|
|
|
static void drop_other_mm_ref(void *info)
|
|
|
|
{
|
|
|
|
struct mm_struct *mm = info;
|
2008-07-08 22:06:40 +00:00
|
|
|
struct mm_struct *active_mm;
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2012-01-13 15:53:35 +00:00
|
|
|
active_mm = this_cpu_read(cpu_tlbstate.active_mm);
|
2008-07-08 22:06:40 +00:00
|
|
|
|
2012-01-13 15:53:35 +00:00
|
|
|
if (active_mm == mm && this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK)
|
2007-07-18 01:37:06 +00:00
|
|
|
leave_mm(smp_processor_id());
|
2007-10-16 18:51:30 +00:00
|
|
|
|
|
|
|
/* If this cpu still has a stale cr3 reference, then make sure
|
|
|
|
it has been flushed. */
|
2012-01-13 15:53:35 +00:00
|
|
|
if (this_cpu_read(xen_current_cr3) == __pa(mm->pgd))
|
2007-10-16 18:51:30 +00:00
|
|
|
load_cr3(swapper_pg_dir);
|
2007-07-18 01:37:06 +00:00
|
|
|
}
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2008-08-19 20:34:22 +00:00
|
|
|
static void xen_drop_mm_ref(struct mm_struct *mm)
|
2007-07-18 01:37:06 +00:00
|
|
|
{
|
2008-12-17 01:34:05 +00:00
|
|
|
cpumask_var_t mask;
|
2007-10-16 18:51:30 +00:00
|
|
|
unsigned cpu;
|
|
|
|
|
2007-07-18 01:37:06 +00:00
|
|
|
if (current->active_mm == mm) {
|
|
|
|
if (current->mm == mm)
|
|
|
|
load_cr3(swapper_pg_dir);
|
|
|
|
else
|
|
|
|
leave_mm(smp_processor_id());
|
2007-10-16 18:51:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Get the "official" set of cpus referring to our pagetable. */
|
2008-12-17 01:34:05 +00:00
|
|
|
if (!alloc_cpumask_var(&mask, GFP_ATOMIC)) {
|
|
|
|
for_each_online_cpu(cpu) {
|
2009-09-24 15:34:51 +00:00
|
|
|
if (!cpumask_test_cpu(cpu, mm_cpumask(mm))
|
2008-12-17 01:34:05 +00:00
|
|
|
&& per_cpu(xen_current_cr3, cpu) != __pa(mm->pgd))
|
|
|
|
continue;
|
|
|
|
smp_call_function_single(cpu, drop_other_mm_ref, mm, 1);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
2009-09-24 15:34:51 +00:00
|
|
|
cpumask_copy(mask, mm_cpumask(mm));
|
2007-10-16 18:51:30 +00:00
|
|
|
|
|
|
|
/* 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))
|
2008-12-17 01:34:05 +00:00
|
|
|
cpumask_set_cpu(cpu, mask);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
|
|
|
|
2008-12-17 01:34:05 +00:00
|
|
|
if (!cpumask_empty(mask))
|
|
|
|
smp_call_function_many(mask, drop_other_mm_ref, mm, 1);
|
|
|
|
free_cpumask_var(mask);
|
2007-07-18 01:37:06 +00:00
|
|
|
}
|
|
|
|
#else
|
2008-08-19 20:34:22 +00:00
|
|
|
static void xen_drop_mm_ref(struct mm_struct *mm)
|
2007-07-18 01:37:06 +00:00
|
|
|
{
|
|
|
|
if (current->active_mm == mm)
|
|
|
|
load_cr3(swapper_pg_dir);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* While a process runs, Xen pins its pagetables, which means that the
|
|
|
|
* hypervisor forces it to be read-only, and it controls all updates
|
|
|
|
* to it. This means that all pagetable updates have to go via the
|
|
|
|
* hypervisor, which is moderately expensive.
|
|
|
|
*
|
|
|
|
* Since we're pulling the pagetable down, we switch to use init_mm,
|
|
|
|
* unpin old process pagetable and mark it all read-write, which
|
|
|
|
* allows further operations on it to be simple memory accesses.
|
|
|
|
*
|
|
|
|
* The only subtle point is that another CPU may be still using the
|
|
|
|
* pagetable because of lazy tlb flushing. This means we need need to
|
|
|
|
* switch all CPUs off this pagetable before we can unpin it.
|
|
|
|
*/
|
2010-12-02 06:57:39 +00:00
|
|
|
static void xen_exit_mmap(struct mm_struct *mm)
|
2007-07-18 01:37:06 +00:00
|
|
|
{
|
|
|
|
get_cpu(); /* make sure we don't move around */
|
2008-08-19 20:34:22 +00:00
|
|
|
xen_drop_mm_ref(mm);
|
2007-07-18 01:37:06 +00:00
|
|
|
put_cpu();
|
2007-07-18 01:37:04 +00:00
|
|
|
|
2007-07-18 01:37:06 +00:00
|
|
|
spin_lock(&mm->page_table_lock);
|
2007-09-25 18:50:00 +00:00
|
|
|
|
|
|
|
/* pgd may not be pinned in the error exit path of execve */
|
2008-08-19 20:34:22 +00:00
|
|
|
if (xen_page_pinned(mm->pgd))
|
2008-10-08 20:01:39 +00:00
|
|
|
xen_pgd_unpin(mm);
|
2007-10-16 18:51:30 +00:00
|
|
|
|
2007-07-18 01:37:06 +00:00
|
|
|
spin_unlock(&mm->page_table_lock);
|
2007-07-18 01:37:04 +00:00
|
|
|
}
|
2008-08-21 00:02:19 +00:00
|
|
|
|
2012-08-21 20:22:40 +00:00
|
|
|
static void xen_post_allocator_init(void);
|
|
|
|
|
2012-07-26 16:47:40 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
static void __init xen_cleanhighmap(unsigned long vaddr,
|
|
|
|
unsigned long vaddr_end)
|
|
|
|
{
|
|
|
|
unsigned long kernel_end = roundup((unsigned long)_brk_end, PMD_SIZE) - 1;
|
|
|
|
pmd_t *pmd = level2_kernel_pgt + pmd_index(vaddr);
|
|
|
|
|
|
|
|
/* NOTE: The loop is more greedy than the cleanup_highmap variant.
|
|
|
|
* We include the PMD passed in on _both_ boundaries. */
|
|
|
|
for (; vaddr <= vaddr_end && (pmd < (level2_kernel_pgt + PAGE_SIZE));
|
|
|
|
pmd++, vaddr += PMD_SIZE) {
|
|
|
|
if (pmd_none(*pmd))
|
|
|
|
continue;
|
|
|
|
if (vaddr < (unsigned long) _text || vaddr > kernel_end)
|
|
|
|
set_pmd(pmd, __pmd(0));
|
|
|
|
}
|
|
|
|
/* In case we did something silly, we should crash in this function
|
|
|
|
* instead of somewhere later and be confusing. */
|
|
|
|
xen_mc_flush();
|
|
|
|
}
|
|
|
|
#endif
|
2012-09-12 15:16:27 +00:00
|
|
|
static void __init xen_pagetable_init(void)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
2012-07-26 16:47:40 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
unsigned long size;
|
|
|
|
unsigned long addr;
|
|
|
|
#endif
|
2012-09-12 15:16:27 +00:00
|
|
|
paging_init();
|
2009-01-28 22:35:01 +00:00
|
|
|
xen_setup_shared_info();
|
2012-07-26 16:47:40 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
|
|
|
|
unsigned long new_mfn_list;
|
|
|
|
|
|
|
|
size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
|
|
|
|
|
|
|
|
/* On 32-bit, we get zero so this never gets executed. */
|
|
|
|
new_mfn_list = xen_revector_p2m_tree();
|
|
|
|
if (new_mfn_list && new_mfn_list != xen_start_info->mfn_list) {
|
|
|
|
/* using __ka address and sticking INVALID_P2M_ENTRY! */
|
|
|
|
memset((void *)xen_start_info->mfn_list, 0xff, size);
|
|
|
|
|
|
|
|
/* We should be in __ka space. */
|
|
|
|
BUG_ON(xen_start_info->mfn_list < __START_KERNEL_map);
|
|
|
|
addr = xen_start_info->mfn_list;
|
|
|
|
/* We roundup to the PMD, which means that if anybody at this stage is
|
|
|
|
* using the __ka address of xen_start_info or xen_start_info->shared_info
|
|
|
|
* they are in going to crash. Fortunatly we have already revectored
|
|
|
|
* in xen_setup_kernel_pagetable and in xen_setup_shared_info. */
|
|
|
|
size = roundup(size, PMD_SIZE);
|
|
|
|
xen_cleanhighmap(addr, addr + size);
|
|
|
|
|
2012-08-14 20:37:31 +00:00
|
|
|
size = PAGE_ALIGN(xen_start_info->nr_pages * sizeof(unsigned long));
|
2012-07-26 16:47:40 +00:00
|
|
|
memblock_free(__pa(xen_start_info->mfn_list), size);
|
|
|
|
/* And revector! Bye bye old array */
|
|
|
|
xen_start_info->mfn_list = new_mfn_list;
|
2012-08-17 13:35:31 +00:00
|
|
|
} else
|
|
|
|
goto skip;
|
2012-07-26 16:47:40 +00:00
|
|
|
}
|
2012-08-14 18:34:00 +00:00
|
|
|
/* At this stage, cleanup_highmap has already cleaned __ka space
|
|
|
|
* from _brk_limit way up to the max_pfn_mapped (which is the end of
|
|
|
|
* the ramdisk). We continue on, erasing PMD entries that point to page
|
|
|
|
* tables - do note that they are accessible at this stage via __va.
|
|
|
|
* For good measure we also round up to the PMD - which means that if
|
|
|
|
* anybody is using __ka address to the initial boot-stack - and try
|
|
|
|
* to use it - they are going to crash. The xen_start_info has been
|
|
|
|
* taken care of already in xen_setup_kernel_pagetable. */
|
|
|
|
addr = xen_start_info->pt_base;
|
|
|
|
size = roundup(xen_start_info->nr_pt_frames * PAGE_SIZE, PMD_SIZE);
|
|
|
|
|
|
|
|
xen_cleanhighmap(addr, addr + size);
|
|
|
|
xen_start_info->pt_base = (unsigned long)__va(__pa(xen_start_info->pt_base));
|
|
|
|
#ifdef DEBUG
|
|
|
|
/* This is superflous and is not neccessary, but you know what
|
|
|
|
* lets do it. The MODULES_VADDR -> MODULES_END should be clear of
|
|
|
|
* anything at this stage. */
|
|
|
|
xen_cleanhighmap(MODULES_VADDR, roundup(MODULES_VADDR, PUD_SIZE) - 1);
|
|
|
|
#endif
|
2012-08-17 13:35:31 +00:00
|
|
|
skip:
|
2012-07-26 16:47:40 +00:00
|
|
|
#endif
|
2009-08-20 11:13:52 +00:00
|
|
|
xen_post_allocator_init();
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
static void xen_write_cr2(unsigned long cr2)
|
|
|
|
{
|
2012-01-13 15:53:35 +00:00
|
|
|
this_cpu_read(xen_vcpu)->arch.cr2 = cr2;
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long xen_read_cr2(void)
|
|
|
|
{
|
2012-01-13 15:53:35 +00:00
|
|
|
return this_cpu_read(xen_vcpu)->arch.cr2;
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
unsigned long xen_read_cr2_direct(void)
|
|
|
|
{
|
2012-01-13 15:53:35 +00:00
|
|
|
return this_cpu_read(xen_vcpu_info.arch.cr2);
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
|
2012-10-31 16:38:31 +00:00
|
|
|
void xen_flush_tlb_all(void)
|
|
|
|
{
|
|
|
|
struct mmuext_op *op;
|
|
|
|
struct multicall_space mcs;
|
|
|
|
|
|
|
|
trace_xen_mmu_flush_tlb_all(0);
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
|
|
|
|
mcs = xen_mc_entry(sizeof(*op));
|
|
|
|
|
|
|
|
op = mcs.args;
|
|
|
|
op->cmd = MMUEXT_TLB_FLUSH_ALL;
|
|
|
|
MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
|
|
|
|
|
|
|
preempt_enable();
|
|
|
|
}
|
2009-01-28 22:35:01 +00:00
|
|
|
static void xen_flush_tlb(void)
|
|
|
|
{
|
|
|
|
struct mmuext_op *op;
|
|
|
|
struct multicall_space mcs;
|
|
|
|
|
2010-12-20 21:15:04 +00:00
|
|
|
trace_xen_mmu_flush_tlb(0);
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
preempt_disable();
|
|
|
|
|
|
|
|
mcs = xen_mc_entry(sizeof(*op));
|
|
|
|
|
|
|
|
op = mcs.args;
|
|
|
|
op->cmd = MMUEXT_TLB_FLUSH_LOCAL;
|
|
|
|
MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
|
|
|
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_flush_tlb_single(unsigned long addr)
|
|
|
|
{
|
|
|
|
struct mmuext_op *op;
|
|
|
|
struct multicall_space mcs;
|
|
|
|
|
2010-12-20 21:15:04 +00:00
|
|
|
trace_xen_mmu_flush_tlb_single(addr);
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
preempt_disable();
|
|
|
|
|
|
|
|
mcs = xen_mc_entry(sizeof(*op));
|
|
|
|
op = mcs.args;
|
|
|
|
op->cmd = MMUEXT_INVLPG_LOCAL;
|
|
|
|
op->arg1.linear_addr = addr & PAGE_MASK;
|
|
|
|
MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
|
|
|
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_flush_tlb_others(const struct cpumask *cpus,
|
x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
x86 has no flush_tlb_range support in instruction level. Currently the
flush_tlb_range just implemented by flushing all page table. That is not
the best solution for all scenarios. In fact, if we just use 'invlpg' to
flush few lines from TLB, we can get the performance gain from later
remain TLB lines accessing.
But the 'invlpg' instruction costs much of time. Its execution time can
compete with cr3 rewriting, and even a bit more on SNB CPU.
So, on a 512 4KB TLB entries CPU, the balance points is at:
(512 - X) * 100ns(assumed TLB refill cost) =
X(TLB flush entries) * 100ns(assumed invlpg cost)
Here, X is 256, that is 1/2 of 512 entries.
But with the mysterious CPU pre-fetcher and page miss handler Unit, the
assumed TLB refill cost is far lower then 100ns in sequential access. And
2 HT siblings in one core makes the memory access more faster if they are
accessing the same memory. So, in the patch, I just do the change when
the target entries is less than 1/16 of whole active tlb entries.
Actually, I have no data support for the percentage '1/16', so any
suggestions are welcomed.
As to hugetlb, guess due to smaller page table, and smaller active TLB
entries, I didn't see benefit via my benchmark, so no optimizing now.
My micro benchmark show in ideal scenarios, the performance improves 70
percent in reading. And in worst scenario, the reading/writing
performance is similar with unpatched 3.4-rc4 kernel.
Here is the reading data on my 2P * 4cores *HT NHM EP machine, with THP
'always':
multi thread testing, '-t' paramter is thread number:
with patch unpatched 3.4-rc4
./mprotect -t 1 14ns 24ns
./mprotect -t 2 13ns 22ns
./mprotect -t 4 12ns 19ns
./mprotect -t 8 14ns 16ns
./mprotect -t 16 28ns 26ns
./mprotect -t 32 54ns 51ns
./mprotect -t 128 200ns 199ns
Single process with sequencial flushing and memory accessing:
with patch unpatched 3.4-rc4
./mprotect 7ns 11ns
./mprotect -p 4096 -l 8 -n 10240
21ns 21ns
[ hpa: http://lkml.kernel.org/r/1B4B44D9196EFF41AE41FDA404FC0A100BFF94@SHSMSX101.ccr.corp.intel.com
has additional performance numbers. ]
Signed-off-by: Alex Shi <alex.shi@intel.com>
Link: http://lkml.kernel.org/r/1340845344-27557-3-git-send-email-alex.shi@intel.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-06-28 01:02:17 +00:00
|
|
|
struct mm_struct *mm, unsigned long start,
|
|
|
|
unsigned long end)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
|
|
|
struct {
|
|
|
|
struct mmuext_op op;
|
2011-06-30 13:12:40 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2009-12-18 09:31:31 +00:00
|
|
|
DECLARE_BITMAP(mask, num_processors);
|
2011-06-30 13:12:40 +00:00
|
|
|
#else
|
|
|
|
DECLARE_BITMAP(mask, NR_CPUS);
|
|
|
|
#endif
|
2009-01-28 22:35:01 +00:00
|
|
|
} *args;
|
|
|
|
struct multicall_space mcs;
|
|
|
|
|
x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
x86 has no flush_tlb_range support in instruction level. Currently the
flush_tlb_range just implemented by flushing all page table. That is not
the best solution for all scenarios. In fact, if we just use 'invlpg' to
flush few lines from TLB, we can get the performance gain from later
remain TLB lines accessing.
But the 'invlpg' instruction costs much of time. Its execution time can
compete with cr3 rewriting, and even a bit more on SNB CPU.
So, on a 512 4KB TLB entries CPU, the balance points is at:
(512 - X) * 100ns(assumed TLB refill cost) =
X(TLB flush entries) * 100ns(assumed invlpg cost)
Here, X is 256, that is 1/2 of 512 entries.
But with the mysterious CPU pre-fetcher and page miss handler Unit, the
assumed TLB refill cost is far lower then 100ns in sequential access. And
2 HT siblings in one core makes the memory access more faster if they are
accessing the same memory. So, in the patch, I just do the change when
the target entries is less than 1/16 of whole active tlb entries.
Actually, I have no data support for the percentage '1/16', so any
suggestions are welcomed.
As to hugetlb, guess due to smaller page table, and smaller active TLB
entries, I didn't see benefit via my benchmark, so no optimizing now.
My micro benchmark show in ideal scenarios, the performance improves 70
percent in reading. And in worst scenario, the reading/writing
performance is similar with unpatched 3.4-rc4 kernel.
Here is the reading data on my 2P * 4cores *HT NHM EP machine, with THP
'always':
multi thread testing, '-t' paramter is thread number:
with patch unpatched 3.4-rc4
./mprotect -t 1 14ns 24ns
./mprotect -t 2 13ns 22ns
./mprotect -t 4 12ns 19ns
./mprotect -t 8 14ns 16ns
./mprotect -t 16 28ns 26ns
./mprotect -t 32 54ns 51ns
./mprotect -t 128 200ns 199ns
Single process with sequencial flushing and memory accessing:
with patch unpatched 3.4-rc4
./mprotect 7ns 11ns
./mprotect -p 4096 -l 8 -n 10240
21ns 21ns
[ hpa: http://lkml.kernel.org/r/1B4B44D9196EFF41AE41FDA404FC0A100BFF94@SHSMSX101.ccr.corp.intel.com
has additional performance numbers. ]
Signed-off-by: Alex Shi <alex.shi@intel.com>
Link: http://lkml.kernel.org/r/1340845344-27557-3-git-send-email-alex.shi@intel.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-06-28 01:02:17 +00:00
|
|
|
trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);
|
2010-12-20 21:15:04 +00:00
|
|
|
|
2009-03-05 01:36:57 +00:00
|
|
|
if (cpumask_empty(cpus))
|
|
|
|
return; /* nothing to do */
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
mcs = xen_mc_entry(sizeof(*args));
|
|
|
|
args = mcs.args;
|
|
|
|
args->op.arg2.vcpumask = to_cpumask(args->mask);
|
|
|
|
|
|
|
|
/* Remove us, and any offline CPUS. */
|
|
|
|
cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
|
|
|
|
cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));
|
|
|
|
|
x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
x86 has no flush_tlb_range support in instruction level. Currently the
flush_tlb_range just implemented by flushing all page table. That is not
the best solution for all scenarios. In fact, if we just use 'invlpg' to
flush few lines from TLB, we can get the performance gain from later
remain TLB lines accessing.
But the 'invlpg' instruction costs much of time. Its execution time can
compete with cr3 rewriting, and even a bit more on SNB CPU.
So, on a 512 4KB TLB entries CPU, the balance points is at:
(512 - X) * 100ns(assumed TLB refill cost) =
X(TLB flush entries) * 100ns(assumed invlpg cost)
Here, X is 256, that is 1/2 of 512 entries.
But with the mysterious CPU pre-fetcher and page miss handler Unit, the
assumed TLB refill cost is far lower then 100ns in sequential access. And
2 HT siblings in one core makes the memory access more faster if they are
accessing the same memory. So, in the patch, I just do the change when
the target entries is less than 1/16 of whole active tlb entries.
Actually, I have no data support for the percentage '1/16', so any
suggestions are welcomed.
As to hugetlb, guess due to smaller page table, and smaller active TLB
entries, I didn't see benefit via my benchmark, so no optimizing now.
My micro benchmark show in ideal scenarios, the performance improves 70
percent in reading. And in worst scenario, the reading/writing
performance is similar with unpatched 3.4-rc4 kernel.
Here is the reading data on my 2P * 4cores *HT NHM EP machine, with THP
'always':
multi thread testing, '-t' paramter is thread number:
with patch unpatched 3.4-rc4
./mprotect -t 1 14ns 24ns
./mprotect -t 2 13ns 22ns
./mprotect -t 4 12ns 19ns
./mprotect -t 8 14ns 16ns
./mprotect -t 16 28ns 26ns
./mprotect -t 32 54ns 51ns
./mprotect -t 128 200ns 199ns
Single process with sequencial flushing and memory accessing:
with patch unpatched 3.4-rc4
./mprotect 7ns 11ns
./mprotect -p 4096 -l 8 -n 10240
21ns 21ns
[ hpa: http://lkml.kernel.org/r/1B4B44D9196EFF41AE41FDA404FC0A100BFF94@SHSMSX101.ccr.corp.intel.com
has additional performance numbers. ]
Signed-off-by: Alex Shi <alex.shi@intel.com>
Link: http://lkml.kernel.org/r/1340845344-27557-3-git-send-email-alex.shi@intel.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-06-28 01:02:17 +00:00
|
|
|
args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
|
2012-08-24 08:55:13 +00:00
|
|
|
if (end != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
|
2009-01-28 22:35:01 +00:00
|
|
|
args->op.cmd = MMUEXT_INVLPG_MULTI;
|
x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
x86 has no flush_tlb_range support in instruction level. Currently the
flush_tlb_range just implemented by flushing all page table. That is not
the best solution for all scenarios. In fact, if we just use 'invlpg' to
flush few lines from TLB, we can get the performance gain from later
remain TLB lines accessing.
But the 'invlpg' instruction costs much of time. Its execution time can
compete with cr3 rewriting, and even a bit more on SNB CPU.
So, on a 512 4KB TLB entries CPU, the balance points is at:
(512 - X) * 100ns(assumed TLB refill cost) =
X(TLB flush entries) * 100ns(assumed invlpg cost)
Here, X is 256, that is 1/2 of 512 entries.
But with the mysterious CPU pre-fetcher and page miss handler Unit, the
assumed TLB refill cost is far lower then 100ns in sequential access. And
2 HT siblings in one core makes the memory access more faster if they are
accessing the same memory. So, in the patch, I just do the change when
the target entries is less than 1/16 of whole active tlb entries.
Actually, I have no data support for the percentage '1/16', so any
suggestions are welcomed.
As to hugetlb, guess due to smaller page table, and smaller active TLB
entries, I didn't see benefit via my benchmark, so no optimizing now.
My micro benchmark show in ideal scenarios, the performance improves 70
percent in reading. And in worst scenario, the reading/writing
performance is similar with unpatched 3.4-rc4 kernel.
Here is the reading data on my 2P * 4cores *HT NHM EP machine, with THP
'always':
multi thread testing, '-t' paramter is thread number:
with patch unpatched 3.4-rc4
./mprotect -t 1 14ns 24ns
./mprotect -t 2 13ns 22ns
./mprotect -t 4 12ns 19ns
./mprotect -t 8 14ns 16ns
./mprotect -t 16 28ns 26ns
./mprotect -t 32 54ns 51ns
./mprotect -t 128 200ns 199ns
Single process with sequencial flushing and memory accessing:
with patch unpatched 3.4-rc4
./mprotect 7ns 11ns
./mprotect -p 4096 -l 8 -n 10240
21ns 21ns
[ hpa: http://lkml.kernel.org/r/1B4B44D9196EFF41AE41FDA404FC0A100BFF94@SHSMSX101.ccr.corp.intel.com
has additional performance numbers. ]
Signed-off-by: Alex Shi <alex.shi@intel.com>
Link: http://lkml.kernel.org/r/1340845344-27557-3-git-send-email-alex.shi@intel.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-06-28 01:02:17 +00:00
|
|
|
args->op.arg1.linear_addr = start;
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long xen_read_cr3(void)
|
|
|
|
{
|
2012-01-13 15:53:35 +00:00
|
|
|
return this_cpu_read(xen_cr3);
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void set_current_cr3(void *v)
|
|
|
|
{
|
2012-01-13 15:53:35 +00:00
|
|
|
this_cpu_write(xen_current_cr3, (unsigned long)v);
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __xen_write_cr3(bool kernel, unsigned long cr3)
|
|
|
|
{
|
2010-12-17 17:17:32 +00:00
|
|
|
struct mmuext_op op;
|
2009-01-28 22:35:01 +00:00
|
|
|
unsigned long mfn;
|
|
|
|
|
2010-12-20 21:15:04 +00:00
|
|
|
trace_xen_mmu_write_cr3(kernel, cr3);
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
if (cr3)
|
|
|
|
mfn = pfn_to_mfn(PFN_DOWN(cr3));
|
|
|
|
else
|
|
|
|
mfn = 0;
|
|
|
|
|
|
|
|
WARN_ON(mfn == 0 && kernel);
|
|
|
|
|
2010-12-17 17:17:32 +00:00
|
|
|
op.cmd = kernel ? MMUEXT_NEW_BASEPTR : MMUEXT_NEW_USER_BASEPTR;
|
|
|
|
op.arg1.mfn = mfn;
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2010-12-17 17:17:32 +00:00
|
|
|
xen_extend_mmuext_op(&op);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
if (kernel) {
|
2012-01-13 15:53:35 +00:00
|
|
|
this_cpu_write(xen_cr3, cr3);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
/* Update xen_current_cr3 once the batch has actually
|
|
|
|
been submitted. */
|
|
|
|
xen_mc_callback(set_current_cr3, (void *)cr3);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
static void xen_write_cr3(unsigned long cr3)
|
|
|
|
{
|
|
|
|
BUG_ON(preemptible());
|
|
|
|
|
|
|
|
xen_mc_batch(); /* disables interrupts */
|
|
|
|
|
|
|
|
/* Update while interrupts are disabled, so its atomic with
|
|
|
|
respect to ipis */
|
2012-01-13 15:53:35 +00:00
|
|
|
this_cpu_write(xen_cr3, cr3);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
__xen_write_cr3(true, cr3);
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
{
|
|
|
|
pgd_t *user_pgd = xen_get_user_pgd(__va(cr3));
|
|
|
|
if (user_pgd)
|
|
|
|
__xen_write_cr3(false, __pa(user_pgd));
|
|
|
|
else
|
|
|
|
__xen_write_cr3(false, 0);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_CPU); /* interrupts restored */
|
|
|
|
}
|
|
|
|
|
2013-02-23 01:35:13 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
/*
|
|
|
|
* At the start of the day - when Xen launches a guest, it has already
|
|
|
|
* built pagetables for the guest. We diligently look over them
|
|
|
|
* in xen_setup_kernel_pagetable and graft as appropiate them in the
|
|
|
|
* init_level4_pgt and its friends. Then when we are happy we load
|
|
|
|
* the new init_level4_pgt - and continue on.
|
|
|
|
*
|
|
|
|
* The generic code starts (start_kernel) and 'init_mem_mapping' sets
|
|
|
|
* up the rest of the pagetables. When it has completed it loads the cr3.
|
|
|
|
* N.B. that baremetal would start at 'start_kernel' (and the early
|
|
|
|
* #PF handler would create bootstrap pagetables) - so we are running
|
|
|
|
* with the same assumptions as what to do when write_cr3 is executed
|
|
|
|
* at this point.
|
|
|
|
*
|
|
|
|
* Since there are no user-page tables at all, we have two variants
|
|
|
|
* of xen_write_cr3 - the early bootup (this one), and the late one
|
|
|
|
* (xen_write_cr3). The reason we have to do that is that in 64-bit
|
|
|
|
* the Linux kernel and user-space are both in ring 3 while the
|
|
|
|
* hypervisor is in ring 0.
|
|
|
|
*/
|
|
|
|
static void __init xen_write_cr3_init(unsigned long cr3)
|
|
|
|
{
|
|
|
|
BUG_ON(preemptible());
|
|
|
|
|
|
|
|
xen_mc_batch(); /* disables interrupts */
|
|
|
|
|
|
|
|
/* Update while interrupts are disabled, so its atomic with
|
|
|
|
respect to ipis */
|
|
|
|
this_cpu_write(xen_cr3, cr3);
|
|
|
|
|
|
|
|
__xen_write_cr3(true, cr3);
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_CPU); /* interrupts restored */
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
static int xen_pgd_alloc(struct mm_struct *mm)
|
|
|
|
{
|
|
|
|
pgd_t *pgd = mm->pgd;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
BUG_ON(PagePinned(virt_to_page(pgd)));
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
{
|
|
|
|
struct page *page = virt_to_page(pgd);
|
|
|
|
pgd_t *user_pgd;
|
|
|
|
|
|
|
|
BUG_ON(page->private != 0);
|
|
|
|
|
|
|
|
ret = -ENOMEM;
|
|
|
|
|
|
|
|
user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
|
|
|
|
page->private = (unsigned long)user_pgd;
|
|
|
|
|
|
|
|
if (user_pgd != NULL) {
|
|
|
|
user_pgd[pgd_index(VSYSCALL_START)] =
|
|
|
|
__pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
|
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
BUG_ON(PagePinned(virt_to_page(xen_get_user_pgd(pgd))));
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
pgd_t *user_pgd = xen_get_user_pgd(pgd);
|
|
|
|
|
|
|
|
if (user_pgd)
|
|
|
|
free_page((unsigned long)user_pgd);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2011-04-19 13:47:31 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
2011-05-12 21:19:53 +00:00
|
|
|
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
|
2009-02-02 21:58:06 +00:00
|
|
|
{
|
|
|
|
/* If there's an existing pte, then don't allow _PAGE_RW to be set */
|
|
|
|
if (pte_val_ma(*ptep) & _PAGE_PRESENT)
|
|
|
|
pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
|
|
|
|
pte_val_ma(pte));
|
2011-04-19 13:47:31 +00:00
|
|
|
|
|
|
|
return pte;
|
|
|
|
}
|
|
|
|
#else /* CONFIG_X86_64 */
|
2011-05-12 21:19:53 +00:00
|
|
|
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
|
2011-04-19 13:47:31 +00:00
|
|
|
{
|
2009-02-02 21:58:06 +00:00
|
|
|
return pte;
|
|
|
|
}
|
2011-04-19 13:47:31 +00:00
|
|
|
#endif /* CONFIG_X86_64 */
|
2009-02-02 21:58:06 +00:00
|
|
|
|
2012-07-09 10:39:05 +00:00
|
|
|
/*
|
|
|
|
* Init-time set_pte while constructing initial pagetables, which
|
|
|
|
* doesn't allow RO page table pages to be remapped RW.
|
|
|
|
*
|
2012-07-09 10:39:06 +00:00
|
|
|
* If there is no MFN for this PFN then this page is initially
|
|
|
|
* ballooned out so clear the PTE (as in decrease_reservation() in
|
|
|
|
* drivers/xen/balloon.c).
|
|
|
|
*
|
2012-07-09 10:39:05 +00:00
|
|
|
* Many of these PTE updates are done on unpinned and writable pages
|
|
|
|
* and doing a hypercall for these is unnecessary and expensive. At
|
|
|
|
* this point it is not possible to tell if a page is pinned or not,
|
|
|
|
* so always write the PTE directly and rely on Xen trapping and
|
|
|
|
* emulating any updates as necessary.
|
|
|
|
*/
|
2011-05-12 21:19:53 +00:00
|
|
|
static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
|
2009-02-02 21:58:06 +00:00
|
|
|
{
|
2012-07-09 10:39:06 +00:00
|
|
|
if (pte_mfn(pte) != INVALID_P2M_ENTRY)
|
|
|
|
pte = mask_rw_pte(ptep, pte);
|
|
|
|
else
|
|
|
|
pte = __pte_ma(0);
|
2009-02-02 21:58:06 +00:00
|
|
|
|
2012-07-09 10:39:05 +00:00
|
|
|
native_set_pte(ptep, pte);
|
2009-02-02 21:58:06 +00:00
|
|
|
}
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2009-03-17 20:30:55 +00:00
|
|
|
static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
|
|
|
|
{
|
|
|
|
struct mmuext_op op;
|
|
|
|
op.cmd = cmd;
|
|
|
|
op.arg1.mfn = pfn_to_mfn(pfn);
|
|
|
|
if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
/* Early in boot, while setting up the initial pagetable, assume
|
|
|
|
everything is pinned. */
|
2011-05-12 21:19:53 +00:00
|
|
|
static void __init xen_alloc_pte_init(struct mm_struct *mm, unsigned long pfn)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
2009-03-17 20:30:55 +00:00
|
|
|
#ifdef CONFIG_FLATMEM
|
|
|
|
BUG_ON(mem_map); /* should only be used early */
|
|
|
|
#endif
|
|
|
|
make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
|
|
|
|
pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Used for pmd and pud */
|
2011-05-12 21:19:53 +00:00
|
|
|
static void __init xen_alloc_pmd_init(struct mm_struct *mm, unsigned long pfn)
|
2009-03-17 20:30:55 +00:00
|
|
|
{
|
2009-01-28 22:35:01 +00:00
|
|
|
#ifdef CONFIG_FLATMEM
|
|
|
|
BUG_ON(mem_map); /* should only be used early */
|
|
|
|
#endif
|
|
|
|
make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Early release_pte assumes that all pts are pinned, since there's
|
|
|
|
only init_mm and anything attached to that is pinned. */
|
2011-05-12 21:19:53 +00:00
|
|
|
static void __init xen_release_pte_init(unsigned long pfn)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
2009-03-17 20:30:55 +00:00
|
|
|
pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);
|
2009-01-28 22:35:01 +00:00
|
|
|
make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
|
|
|
|
}
|
|
|
|
|
2011-05-12 21:19:53 +00:00
|
|
|
static void __init xen_release_pmd_init(unsigned long pfn)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
2009-03-17 20:30:55 +00:00
|
|
|
make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
|
2010-12-17 22:58:43 +00:00
|
|
|
static inline void __pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
|
|
|
|
{
|
|
|
|
struct multicall_space mcs;
|
|
|
|
struct mmuext_op *op;
|
|
|
|
|
|
|
|
mcs = __xen_mc_entry(sizeof(*op));
|
|
|
|
op = mcs.args;
|
|
|
|
op->cmd = cmd;
|
|
|
|
op->arg1.mfn = pfn_to_mfn(pfn);
|
|
|
|
|
|
|
|
MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __set_pfn_prot(unsigned long pfn, pgprot_t prot)
|
|
|
|
{
|
|
|
|
struct multicall_space mcs;
|
|
|
|
unsigned long addr = (unsigned long)__va(pfn << PAGE_SHIFT);
|
|
|
|
|
|
|
|
mcs = __xen_mc_entry(0);
|
|
|
|
MULTI_update_va_mapping(mcs.mc, (unsigned long)addr,
|
|
|
|
pfn_pte(pfn, prot), 0);
|
|
|
|
}
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
/* This needs to make sure the new pte page is pinned iff its being
|
|
|
|
attached to a pinned pagetable. */
|
2010-12-17 22:58:43 +00:00
|
|
|
static inline void xen_alloc_ptpage(struct mm_struct *mm, unsigned long pfn,
|
|
|
|
unsigned level)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
2010-12-17 22:58:43 +00:00
|
|
|
bool pinned = PagePinned(virt_to_page(mm->pgd));
|
|
|
|
|
2010-12-17 22:21:17 +00:00
|
|
|
trace_xen_mmu_alloc_ptpage(mm, pfn, level, pinned);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2010-12-17 22:21:17 +00:00
|
|
|
if (pinned) {
|
2010-12-17 22:58:43 +00:00
|
|
|
struct page *page = pfn_to_page(pfn);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
SetPagePinned(page);
|
|
|
|
|
|
|
|
if (!PageHighMem(page)) {
|
2010-12-17 22:58:43 +00:00
|
|
|
xen_mc_batch();
|
|
|
|
|
|
|
|
__set_pfn_prot(pfn, PAGE_KERNEL_RO);
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
if (level == PT_PTE && USE_SPLIT_PTLOCKS)
|
2010-12-17 22:58:43 +00:00
|
|
|
__pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
2009-01-28 22:35:01 +00:00
|
|
|
} else {
|
|
|
|
/* make sure there are no stray mappings of
|
|
|
|
this page */
|
|
|
|
kmap_flush_unused();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_alloc_pte(struct mm_struct *mm, unsigned long pfn)
|
|
|
|
{
|
|
|
|
xen_alloc_ptpage(mm, pfn, PT_PTE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_alloc_pmd(struct mm_struct *mm, unsigned long pfn)
|
|
|
|
{
|
|
|
|
xen_alloc_ptpage(mm, pfn, PT_PMD);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This should never happen until we're OK to use struct page */
|
2010-12-17 22:58:43 +00:00
|
|
|
static inline void xen_release_ptpage(unsigned long pfn, unsigned level)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
|
|
|
struct page *page = pfn_to_page(pfn);
|
2010-12-17 22:21:17 +00:00
|
|
|
bool pinned = PagePinned(page);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2010-12-17 22:21:17 +00:00
|
|
|
trace_xen_mmu_release_ptpage(pfn, level, pinned);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2010-12-17 22:21:17 +00:00
|
|
|
if (pinned) {
|
2009-01-28 22:35:01 +00:00
|
|
|
if (!PageHighMem(page)) {
|
2010-12-17 22:58:43 +00:00
|
|
|
xen_mc_batch();
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
if (level == PT_PTE && USE_SPLIT_PTLOCKS)
|
2010-12-17 22:58:43 +00:00
|
|
|
__pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);
|
|
|
|
|
|
|
|
__set_pfn_prot(pfn, PAGE_KERNEL);
|
|
|
|
|
|
|
|
xen_mc_issue(PARAVIRT_LAZY_MMU);
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
ClearPagePinned(page);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_release_pte(unsigned long pfn)
|
|
|
|
{
|
|
|
|
xen_release_ptpage(pfn, PT_PTE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_release_pmd(unsigned long pfn)
|
|
|
|
{
|
|
|
|
xen_release_ptpage(pfn, PT_PMD);
|
|
|
|
}
|
|
|
|
|
|
|
|
#if PAGETABLE_LEVELS == 4
|
|
|
|
static void xen_alloc_pud(struct mm_struct *mm, unsigned long pfn)
|
|
|
|
{
|
|
|
|
xen_alloc_ptpage(mm, pfn, PT_PUD);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xen_release_pud(unsigned long pfn)
|
|
|
|
{
|
|
|
|
xen_release_ptpage(pfn, PT_PUD);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
void __init xen_reserve_top(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
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);
|
|
|
|
#endif /* CONFIG_X86_32 */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Like __va(), but returns address in the kernel mapping (which is
|
|
|
|
* all we have until the physical memory mapping has been set up.
|
|
|
|
*/
|
|
|
|
static void *__ka(phys_addr_t paddr)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
return (void *)(paddr + __START_KERNEL_map);
|
|
|
|
#else
|
|
|
|
return __va(paddr);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Convert a machine address to physical address */
|
|
|
|
static unsigned long m2p(phys_addr_t maddr)
|
|
|
|
{
|
|
|
|
phys_addr_t paddr;
|
|
|
|
|
|
|
|
maddr &= PTE_PFN_MASK;
|
|
|
|
paddr = mfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;
|
|
|
|
|
|
|
|
return paddr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Convert a machine address to kernel virtual */
|
|
|
|
static void *m2v(phys_addr_t maddr)
|
|
|
|
{
|
|
|
|
return __ka(m2p(maddr));
|
|
|
|
}
|
|
|
|
|
2010-09-02 14:45:43 +00:00
|
|
|
/* Set the page permissions on an identity-mapped pages */
|
xen/mmu: On early bootup, flush the TLB when changing RO->RW bits Xen provided pagetables.
Occassionaly on a DL380 G4 the guest would crash quite early with this:
(XEN) d244:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from ffffffff84dc7000:
(XEN) L4[0x1ff] = 00000000c3f18067 0000000000001789
(XEN) L3[0x1fe] = 00000000c3f14067 000000000000178d
(XEN) L2[0x026] = 00000000dc8b2067 0000000000004def
(XEN) L1[0x1c7] = 00100000dc8da067 0000000000004dc7
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 244 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.1.3OVM x86_64 debug=n Not tainted ]----
(XEN) CPU: 3
(XEN) RIP: e033:[<ffffffff81263f22>]
(XEN) RFLAGS: 0000000000000216 EM: 1 CONTEXT: pv guest
(XEN) rax: 0000000000000000 rbx: ffffffff81785f88 rcx: 000000000000003f
(XEN) rdx: 0000000000000000 rsi: 00000000dc8da063 rdi: ffffffff84dc7000
The offending code shows it to be a loop writting the value zero
(%rax) in the %rdi (the L4 provided by Xen) register:
0: 44 00 00 add %r8b,(%rax)
3: 31 c0 xor %eax,%eax
5: b9 40 00 00 00 mov $0x40,%ecx
a: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
11: 00 00
13: ff c9 dec %ecx
15:* 48 89 07 mov %rax,(%rdi) <-- trapping instruction
18: 48 89 47 08 mov %rax,0x8(%rdi)
1c: 48 89 47 10 mov %rax,0x10(%rdi)
which fails. xen_setup_kernel_pagetable recycles some of the Xen's
page-table entries when it has switched over to its Linux page-tables.
Right before try to clear the page, we make a hypercall to change
it from _RO to _RW and that works (otherwise we would hit an BUG()).
And the _RW flag is set for that page:
(XEN) L1[0x1c7] = 001000004885f067 0000000000004dc7
The error code is 3, so PFEC_page_present and PFEC_write_access, so page is
present (correct), and we tried to write to the page, but a violation
occurred. The one theory is that the the page entries in hardware
(which are cached) are not up to date with what we just set. Especially
as we have just done an CR3 write and flushed the multicalls.
This patch does solve the problem by flusing out the TLB page
entry after changing it from _RO to _RW and we don't hit this
issue anymore.
Fixed-Oracle-Bug: 16243091 [ON OCCASIONS VM START GOES INTO
'CRASH' STATE: CLEAR_PAGE+0X12 ON HP DL380 G4]
Reported-and-Tested-by: Saar Maoz <Saar.Maoz@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-29 14:20:56 +00:00
|
|
|
static void set_page_prot_flags(void *addr, pgprot_t prot, unsigned long flags)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
|
|
|
unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
|
|
|
|
pte_t pte = pfn_pte(pfn, prot);
|
|
|
|
|
xen/mmu: On early bootup, flush the TLB when changing RO->RW bits Xen provided pagetables.
Occassionaly on a DL380 G4 the guest would crash quite early with this:
(XEN) d244:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from ffffffff84dc7000:
(XEN) L4[0x1ff] = 00000000c3f18067 0000000000001789
(XEN) L3[0x1fe] = 00000000c3f14067 000000000000178d
(XEN) L2[0x026] = 00000000dc8b2067 0000000000004def
(XEN) L1[0x1c7] = 00100000dc8da067 0000000000004dc7
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 244 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.1.3OVM x86_64 debug=n Not tainted ]----
(XEN) CPU: 3
(XEN) RIP: e033:[<ffffffff81263f22>]
(XEN) RFLAGS: 0000000000000216 EM: 1 CONTEXT: pv guest
(XEN) rax: 0000000000000000 rbx: ffffffff81785f88 rcx: 000000000000003f
(XEN) rdx: 0000000000000000 rsi: 00000000dc8da063 rdi: ffffffff84dc7000
The offending code shows it to be a loop writting the value zero
(%rax) in the %rdi (the L4 provided by Xen) register:
0: 44 00 00 add %r8b,(%rax)
3: 31 c0 xor %eax,%eax
5: b9 40 00 00 00 mov $0x40,%ecx
a: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
11: 00 00
13: ff c9 dec %ecx
15:* 48 89 07 mov %rax,(%rdi) <-- trapping instruction
18: 48 89 47 08 mov %rax,0x8(%rdi)
1c: 48 89 47 10 mov %rax,0x10(%rdi)
which fails. xen_setup_kernel_pagetable recycles some of the Xen's
page-table entries when it has switched over to its Linux page-tables.
Right before try to clear the page, we make a hypercall to change
it from _RO to _RW and that works (otherwise we would hit an BUG()).
And the _RW flag is set for that page:
(XEN) L1[0x1c7] = 001000004885f067 0000000000004dc7
The error code is 3, so PFEC_page_present and PFEC_write_access, so page is
present (correct), and we tried to write to the page, but a violation
occurred. The one theory is that the the page entries in hardware
(which are cached) are not up to date with what we just set. Especially
as we have just done an CR3 write and flushed the multicalls.
This patch does solve the problem by flusing out the TLB page
entry after changing it from _RO to _RW and we don't hit this
issue anymore.
Fixed-Oracle-Bug: 16243091 [ON OCCASIONS VM START GOES INTO
'CRASH' STATE: CLEAR_PAGE+0X12 ON HP DL380 G4]
Reported-and-Tested-by: Saar Maoz <Saar.Maoz@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-29 14:20:56 +00:00
|
|
|
if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, flags))
|
2009-01-28 22:35:01 +00:00
|
|
|
BUG();
|
|
|
|
}
|
xen/mmu: On early bootup, flush the TLB when changing RO->RW bits Xen provided pagetables.
Occassionaly on a DL380 G4 the guest would crash quite early with this:
(XEN) d244:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from ffffffff84dc7000:
(XEN) L4[0x1ff] = 00000000c3f18067 0000000000001789
(XEN) L3[0x1fe] = 00000000c3f14067 000000000000178d
(XEN) L2[0x026] = 00000000dc8b2067 0000000000004def
(XEN) L1[0x1c7] = 00100000dc8da067 0000000000004dc7
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 244 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.1.3OVM x86_64 debug=n Not tainted ]----
(XEN) CPU: 3
(XEN) RIP: e033:[<ffffffff81263f22>]
(XEN) RFLAGS: 0000000000000216 EM: 1 CONTEXT: pv guest
(XEN) rax: 0000000000000000 rbx: ffffffff81785f88 rcx: 000000000000003f
(XEN) rdx: 0000000000000000 rsi: 00000000dc8da063 rdi: ffffffff84dc7000
The offending code shows it to be a loop writting the value zero
(%rax) in the %rdi (the L4 provided by Xen) register:
0: 44 00 00 add %r8b,(%rax)
3: 31 c0 xor %eax,%eax
5: b9 40 00 00 00 mov $0x40,%ecx
a: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
11: 00 00
13: ff c9 dec %ecx
15:* 48 89 07 mov %rax,(%rdi) <-- trapping instruction
18: 48 89 47 08 mov %rax,0x8(%rdi)
1c: 48 89 47 10 mov %rax,0x10(%rdi)
which fails. xen_setup_kernel_pagetable recycles some of the Xen's
page-table entries when it has switched over to its Linux page-tables.
Right before try to clear the page, we make a hypercall to change
it from _RO to _RW and that works (otherwise we would hit an BUG()).
And the _RW flag is set for that page:
(XEN) L1[0x1c7] = 001000004885f067 0000000000004dc7
The error code is 3, so PFEC_page_present and PFEC_write_access, so page is
present (correct), and we tried to write to the page, but a violation
occurred. The one theory is that the the page entries in hardware
(which are cached) are not up to date with what we just set. Especially
as we have just done an CR3 write and flushed the multicalls.
This patch does solve the problem by flusing out the TLB page
entry after changing it from _RO to _RW and we don't hit this
issue anymore.
Fixed-Oracle-Bug: 16243091 [ON OCCASIONS VM START GOES INTO
'CRASH' STATE: CLEAR_PAGE+0X12 ON HP DL380 G4]
Reported-and-Tested-by: Saar Maoz <Saar.Maoz@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-29 14:20:56 +00:00
|
|
|
static void set_page_prot(void *addr, pgprot_t prot)
|
|
|
|
{
|
|
|
|
return set_page_prot_flags(addr, prot, UVMF_NONE);
|
|
|
|
}
|
2012-07-12 17:59:36 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
2011-05-12 21:19:53 +00:00
|
|
|
static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
|
|
|
unsigned pmdidx, pteidx;
|
|
|
|
unsigned ident_pte;
|
|
|
|
unsigned long pfn;
|
|
|
|
|
2010-08-26 23:23:51 +00:00
|
|
|
level1_ident_pgt = extend_brk(sizeof(pte_t) * LEVEL1_IDENT_ENTRIES,
|
|
|
|
PAGE_SIZE);
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
ident_pte = 0;
|
|
|
|
pfn = 0;
|
|
|
|
for (pmdidx = 0; pmdidx < PTRS_PER_PMD && pfn < max_pfn; pmdidx++) {
|
|
|
|
pte_t *pte_page;
|
|
|
|
|
|
|
|
/* Reuse or allocate a page of ptes */
|
|
|
|
if (pmd_present(pmd[pmdidx]))
|
|
|
|
pte_page = m2v(pmd[pmdidx].pmd);
|
|
|
|
else {
|
|
|
|
/* Check for free pte pages */
|
2010-08-26 23:23:51 +00:00
|
|
|
if (ident_pte == LEVEL1_IDENT_ENTRIES)
|
2009-01-28 22:35:01 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
pte_page = &level1_ident_pgt[ident_pte];
|
|
|
|
ident_pte += PTRS_PER_PTE;
|
|
|
|
|
|
|
|
pmd[pmdidx] = __pmd(__pa(pte_page) | _PAGE_TABLE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Install mappings */
|
|
|
|
for (pteidx = 0; pteidx < PTRS_PER_PTE; pteidx++, pfn++) {
|
|
|
|
pte_t pte;
|
|
|
|
|
2011-06-03 09:51:34 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
if (pfn > max_pfn_mapped)
|
|
|
|
max_pfn_mapped = pfn;
|
|
|
|
#endif
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
if (!pte_none(pte_page[pteidx]))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
pte = pfn_pte(pfn, PAGE_KERNEL_EXEC);
|
|
|
|
pte_page[pteidx] = pte;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (pteidx = 0; pteidx < ident_pte; pteidx += PTRS_PER_PTE)
|
|
|
|
set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);
|
|
|
|
|
|
|
|
set_page_prot(pmd, PAGE_KERNEL_RO);
|
|
|
|
}
|
2012-07-12 17:59:36 +00:00
|
|
|
#endif
|
2010-09-30 11:37:26 +00:00
|
|
|
void __init xen_setup_machphys_mapping(void)
|
|
|
|
{
|
|
|
|
struct xen_machphys_mapping mapping;
|
|
|
|
|
|
|
|
if (HYPERVISOR_memory_op(XENMEM_machphys_mapping, &mapping) == 0) {
|
|
|
|
machine_to_phys_mapping = (unsigned long *)mapping.v_start;
|
xen/x86: replace order-based range checking of M2P table by linear one
The order-based approach is not only less efficient (requiring a shift
and a compare, typical generated code looking like this
mov eax, [machine_to_phys_order]
mov ecx, eax
shr ebx, cl
test ebx, ebx
jnz ...
whereas a direct check requires just a compare, like in
cmp ebx, [machine_to_phys_nr]
jae ...
), but also slightly dangerous in the 32-on-64 case - the element
address calculation can wrap if the next power of two boundary is
sufficiently far away from the actual upper limit of the table, and
hence can result in user space addresses being accessed (with it being
unknown what may actually be mapped there).
Additionally, the elimination of the mistaken use of fls() here (should
have been __fls()) fixes a latent issue on x86-64 that would trigger
if the code was run on a system with memory extending beyond the 44-bit
boundary.
CC: stable@kernel.org
Signed-off-by: Jan Beulich <jbeulich@novell.com>
[v1: Based on Jeremy's feedback]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2011-08-16 14:07:41 +00:00
|
|
|
machine_to_phys_nr = mapping.max_mfn + 1;
|
2010-09-30 11:37:26 +00:00
|
|
|
} else {
|
xen/x86: replace order-based range checking of M2P table by linear one
The order-based approach is not only less efficient (requiring a shift
and a compare, typical generated code looking like this
mov eax, [machine_to_phys_order]
mov ecx, eax
shr ebx, cl
test ebx, ebx
jnz ...
whereas a direct check requires just a compare, like in
cmp ebx, [machine_to_phys_nr]
jae ...
), but also slightly dangerous in the 32-on-64 case - the element
address calculation can wrap if the next power of two boundary is
sufficiently far away from the actual upper limit of the table, and
hence can result in user space addresses being accessed (with it being
unknown what may actually be mapped there).
Additionally, the elimination of the mistaken use of fls() here (should
have been __fls()) fixes a latent issue on x86-64 that would trigger
if the code was run on a system with memory extending beyond the 44-bit
boundary.
CC: stable@kernel.org
Signed-off-by: Jan Beulich <jbeulich@novell.com>
[v1: Based on Jeremy's feedback]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2011-08-16 14:07:41 +00:00
|
|
|
machine_to_phys_nr = MACH2PHYS_NR_ENTRIES;
|
2010-09-30 11:37:26 +00:00
|
|
|
}
|
xen/x86: replace order-based range checking of M2P table by linear one
The order-based approach is not only less efficient (requiring a shift
and a compare, typical generated code looking like this
mov eax, [machine_to_phys_order]
mov ecx, eax
shr ebx, cl
test ebx, ebx
jnz ...
whereas a direct check requires just a compare, like in
cmp ebx, [machine_to_phys_nr]
jae ...
), but also slightly dangerous in the 32-on-64 case - the element
address calculation can wrap if the next power of two boundary is
sufficiently far away from the actual upper limit of the table, and
hence can result in user space addresses being accessed (with it being
unknown what may actually be mapped there).
Additionally, the elimination of the mistaken use of fls() here (should
have been __fls()) fixes a latent issue on x86-64 that would trigger
if the code was run on a system with memory extending beyond the 44-bit
boundary.
CC: stable@kernel.org
Signed-off-by: Jan Beulich <jbeulich@novell.com>
[v1: Based on Jeremy's feedback]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2011-08-16 14:07:41 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
2011-09-15 07:52:40 +00:00
|
|
|
WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
|
|
|
|
< machine_to_phys_mapping);
|
xen/x86: replace order-based range checking of M2P table by linear one
The order-based approach is not only less efficient (requiring a shift
and a compare, typical generated code looking like this
mov eax, [machine_to_phys_order]
mov ecx, eax
shr ebx, cl
test ebx, ebx
jnz ...
whereas a direct check requires just a compare, like in
cmp ebx, [machine_to_phys_nr]
jae ...
), but also slightly dangerous in the 32-on-64 case - the element
address calculation can wrap if the next power of two boundary is
sufficiently far away from the actual upper limit of the table, and
hence can result in user space addresses being accessed (with it being
unknown what may actually be mapped there).
Additionally, the elimination of the mistaken use of fls() here (should
have been __fls()) fixes a latent issue on x86-64 that would trigger
if the code was run on a system with memory extending beyond the 44-bit
boundary.
CC: stable@kernel.org
Signed-off-by: Jan Beulich <jbeulich@novell.com>
[v1: Based on Jeremy's feedback]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2011-08-16 14:07:41 +00:00
|
|
|
#endif
|
2010-09-30 11:37:26 +00:00
|
|
|
}
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
static void convert_pfn_mfn(void *v)
|
|
|
|
{
|
|
|
|
pte_t *pte = v;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* All levels are converted the same way, so just treat them
|
|
|
|
as ptes. */
|
|
|
|
for (i = 0; i < PTRS_PER_PTE; i++)
|
|
|
|
pte[i] = xen_make_pte(pte[i].pte);
|
|
|
|
}
|
2012-07-26 16:00:56 +00:00
|
|
|
static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
|
|
|
|
unsigned long addr)
|
|
|
|
{
|
|
|
|
if (*pt_base == PFN_DOWN(__pa(addr))) {
|
xen/mmu: On early bootup, flush the TLB when changing RO->RW bits Xen provided pagetables.
Occassionaly on a DL380 G4 the guest would crash quite early with this:
(XEN) d244:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from ffffffff84dc7000:
(XEN) L4[0x1ff] = 00000000c3f18067 0000000000001789
(XEN) L3[0x1fe] = 00000000c3f14067 000000000000178d
(XEN) L2[0x026] = 00000000dc8b2067 0000000000004def
(XEN) L1[0x1c7] = 00100000dc8da067 0000000000004dc7
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 244 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.1.3OVM x86_64 debug=n Not tainted ]----
(XEN) CPU: 3
(XEN) RIP: e033:[<ffffffff81263f22>]
(XEN) RFLAGS: 0000000000000216 EM: 1 CONTEXT: pv guest
(XEN) rax: 0000000000000000 rbx: ffffffff81785f88 rcx: 000000000000003f
(XEN) rdx: 0000000000000000 rsi: 00000000dc8da063 rdi: ffffffff84dc7000
The offending code shows it to be a loop writting the value zero
(%rax) in the %rdi (the L4 provided by Xen) register:
0: 44 00 00 add %r8b,(%rax)
3: 31 c0 xor %eax,%eax
5: b9 40 00 00 00 mov $0x40,%ecx
a: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
11: 00 00
13: ff c9 dec %ecx
15:* 48 89 07 mov %rax,(%rdi) <-- trapping instruction
18: 48 89 47 08 mov %rax,0x8(%rdi)
1c: 48 89 47 10 mov %rax,0x10(%rdi)
which fails. xen_setup_kernel_pagetable recycles some of the Xen's
page-table entries when it has switched over to its Linux page-tables.
Right before try to clear the page, we make a hypercall to change
it from _RO to _RW and that works (otherwise we would hit an BUG()).
And the _RW flag is set for that page:
(XEN) L1[0x1c7] = 001000004885f067 0000000000004dc7
The error code is 3, so PFEC_page_present and PFEC_write_access, so page is
present (correct), and we tried to write to the page, but a violation
occurred. The one theory is that the the page entries in hardware
(which are cached) are not up to date with what we just set. Especially
as we have just done an CR3 write and flushed the multicalls.
This patch does solve the problem by flusing out the TLB page
entry after changing it from _RO to _RW and we don't hit this
issue anymore.
Fixed-Oracle-Bug: 16243091 [ON OCCASIONS VM START GOES INTO
'CRASH' STATE: CLEAR_PAGE+0X12 ON HP DL380 G4]
Reported-and-Tested-by: Saar Maoz <Saar.Maoz@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-29 14:20:56 +00:00
|
|
|
set_page_prot_flags((void *)addr, PAGE_KERNEL, UVMF_INVLPG);
|
2012-07-26 16:00:56 +00:00
|
|
|
clear_page((void *)addr);
|
|
|
|
(*pt_base)++;
|
|
|
|
}
|
|
|
|
if (*pt_end == PFN_DOWN(__pa(addr))) {
|
xen/mmu: On early bootup, flush the TLB when changing RO->RW bits Xen provided pagetables.
Occassionaly on a DL380 G4 the guest would crash quite early with this:
(XEN) d244:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from ffffffff84dc7000:
(XEN) L4[0x1ff] = 00000000c3f18067 0000000000001789
(XEN) L3[0x1fe] = 00000000c3f14067 000000000000178d
(XEN) L2[0x026] = 00000000dc8b2067 0000000000004def
(XEN) L1[0x1c7] = 00100000dc8da067 0000000000004dc7
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 244 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.1.3OVM x86_64 debug=n Not tainted ]----
(XEN) CPU: 3
(XEN) RIP: e033:[<ffffffff81263f22>]
(XEN) RFLAGS: 0000000000000216 EM: 1 CONTEXT: pv guest
(XEN) rax: 0000000000000000 rbx: ffffffff81785f88 rcx: 000000000000003f
(XEN) rdx: 0000000000000000 rsi: 00000000dc8da063 rdi: ffffffff84dc7000
The offending code shows it to be a loop writting the value zero
(%rax) in the %rdi (the L4 provided by Xen) register:
0: 44 00 00 add %r8b,(%rax)
3: 31 c0 xor %eax,%eax
5: b9 40 00 00 00 mov $0x40,%ecx
a: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
11: 00 00
13: ff c9 dec %ecx
15:* 48 89 07 mov %rax,(%rdi) <-- trapping instruction
18: 48 89 47 08 mov %rax,0x8(%rdi)
1c: 48 89 47 10 mov %rax,0x10(%rdi)
which fails. xen_setup_kernel_pagetable recycles some of the Xen's
page-table entries when it has switched over to its Linux page-tables.
Right before try to clear the page, we make a hypercall to change
it from _RO to _RW and that works (otherwise we would hit an BUG()).
And the _RW flag is set for that page:
(XEN) L1[0x1c7] = 001000004885f067 0000000000004dc7
The error code is 3, so PFEC_page_present and PFEC_write_access, so page is
present (correct), and we tried to write to the page, but a violation
occurred. The one theory is that the the page entries in hardware
(which are cached) are not up to date with what we just set. Especially
as we have just done an CR3 write and flushed the multicalls.
This patch does solve the problem by flusing out the TLB page
entry after changing it from _RO to _RW and we don't hit this
issue anymore.
Fixed-Oracle-Bug: 16243091 [ON OCCASIONS VM START GOES INTO
'CRASH' STATE: CLEAR_PAGE+0X12 ON HP DL380 G4]
Reported-and-Tested-by: Saar Maoz <Saar.Maoz@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-29 14:20:56 +00:00
|
|
|
set_page_prot_flags((void *)addr, PAGE_KERNEL, UVMF_INVLPG);
|
2012-07-26 16:00:56 +00:00
|
|
|
clear_page((void *)addr);
|
|
|
|
(*pt_end)--;
|
|
|
|
}
|
|
|
|
}
|
2009-01-28 22:35:01 +00:00
|
|
|
/*
|
2011-03-17 19:24:16 +00:00
|
|
|
* Set up the initial kernel pagetable.
|
2009-01-28 22:35:01 +00:00
|
|
|
*
|
|
|
|
* We can construct this by grafting the Xen provided pagetable into
|
|
|
|
* head_64.S's preconstructed pagetables. We copy the Xen L2's into
|
|
|
|
* level2_ident_pgt, level2_kernel_pgt and level2_fixmap_pgt. This
|
|
|
|
* means that only the kernel has a physical mapping to start with -
|
|
|
|
* but that's enough to get __va working. We need to fill in the rest
|
|
|
|
* of the physical mapping once some sort of allocator has been set
|
|
|
|
* up.
|
|
|
|
*/
|
2012-06-29 02:47:35 +00:00
|
|
|
void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
|
|
|
pud_t *l3;
|
|
|
|
pmd_t *l2;
|
2012-07-26 16:00:56 +00:00
|
|
|
unsigned long addr[3];
|
|
|
|
unsigned long pt_base, pt_end;
|
|
|
|
unsigned i;
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2011-02-18 11:32:40 +00:00
|
|
|
/* max_pfn_mapped is the last pfn mapped in the initial memory
|
|
|
|
* mappings. Considering that on Xen after the kernel mappings we
|
|
|
|
* have the mappings of some pages that don't exist in pfn space, we
|
|
|
|
* set max_pfn_mapped to the last real pfn mapped. */
|
|
|
|
max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->mfn_list));
|
|
|
|
|
2012-07-26 16:00:56 +00:00
|
|
|
pt_base = PFN_DOWN(__pa(xen_start_info->pt_base));
|
|
|
|
pt_end = pt_base + xen_start_info->nr_pt_frames;
|
|
|
|
|
2009-01-28 22:35:01 +00:00
|
|
|
/* Zap identity mapping */
|
|
|
|
init_level4_pgt[0] = __pgd(0);
|
|
|
|
|
|
|
|
/* Pre-constructed entries are in pfn, so convert to mfn */
|
2012-07-12 17:55:25 +00:00
|
|
|
/* L4[272] -> level3_ident_pgt
|
|
|
|
* L4[511] -> level3_kernel_pgt */
|
2009-01-28 22:35:01 +00:00
|
|
|
convert_pfn_mfn(init_level4_pgt);
|
2012-07-12 17:55:25 +00:00
|
|
|
|
|
|
|
/* L3_i[0] -> level2_ident_pgt */
|
2009-01-28 22:35:01 +00:00
|
|
|
convert_pfn_mfn(level3_ident_pgt);
|
2012-07-12 17:55:25 +00:00
|
|
|
/* L3_k[510] -> level2_kernel_pgt
|
|
|
|
* L3_i[511] -> level2_fixmap_pgt */
|
2009-01-28 22:35:01 +00:00
|
|
|
convert_pfn_mfn(level3_kernel_pgt);
|
|
|
|
|
2012-07-12 17:55:25 +00:00
|
|
|
/* We get [511][511] and have Xen's version of level2_kernel_pgt */
|
2009-01-28 22:35:01 +00:00
|
|
|
l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
|
|
|
|
l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);
|
|
|
|
|
2012-07-26 16:00:56 +00:00
|
|
|
addr[0] = (unsigned long)pgd;
|
|
|
|
addr[1] = (unsigned long)l3;
|
|
|
|
addr[2] = (unsigned long)l2;
|
2012-07-12 17:55:25 +00:00
|
|
|
/* Graft it onto L4[272][0]. Note that we creating an aliasing problem:
|
|
|
|
* Both L4[272][0] and L4[511][511] have entries that point to the same
|
|
|
|
* L2 (PMD) tables. Meaning that if you modify it in __va space
|
|
|
|
* it will be also modified in the __ka space! (But if you just
|
|
|
|
* modify the PMD table to point to other PTE's or none, then you
|
|
|
|
* are OK - which is what cleanup_highmap does) */
|
2012-07-26 15:57:04 +00:00
|
|
|
copy_page(level2_ident_pgt, l2);
|
2012-07-12 17:55:25 +00:00
|
|
|
/* Graft it onto L4[511][511] */
|
2012-07-26 15:57:04 +00:00
|
|
|
copy_page(level2_kernel_pgt, l2);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2012-07-12 17:55:25 +00:00
|
|
|
/* Get [511][510] and graft that in level2_fixmap_pgt */
|
2009-01-28 22:35:01 +00:00
|
|
|
l3 = m2v(pgd[pgd_index(__START_KERNEL_map + PMD_SIZE)].pgd);
|
|
|
|
l2 = m2v(l3[pud_index(__START_KERNEL_map + PMD_SIZE)].pud);
|
2012-07-26 15:57:04 +00:00
|
|
|
copy_page(level2_fixmap_pgt, l2);
|
2012-07-12 17:55:25 +00:00
|
|
|
/* Note that we don't do anything with level1_fixmap_pgt which
|
|
|
|
* we don't need. */
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
/* Make pagetable pieces RO */
|
|
|
|
set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
|
|
|
|
set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
|
|
|
|
set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
|
|
|
|
set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
|
2012-07-12 17:59:36 +00:00
|
|
|
set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
|
2009-01-28 22:35:01 +00:00
|
|
|
set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
|
|
|
|
set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);
|
|
|
|
|
|
|
|
/* Pin down new L4 */
|
|
|
|
pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
|
|
|
|
PFN_DOWN(__pa_symbol(init_level4_pgt)));
|
|
|
|
|
|
|
|
/* Unpin Xen-provided one */
|
|
|
|
pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At this stage there can be no user pgd, and no page
|
|
|
|
* structure to attach it to, so make sure we just set kernel
|
|
|
|
* pgd.
|
|
|
|
*/
|
|
|
|
xen_mc_batch();
|
2012-07-26 16:00:56 +00:00
|
|
|
__xen_write_cr3(true, __pa(init_level4_pgt));
|
2009-01-28 22:35:01 +00:00
|
|
|
xen_mc_issue(PARAVIRT_LAZY_CPU);
|
|
|
|
|
2012-07-26 16:00:56 +00:00
|
|
|
/* We can't that easily rip out L3 and L2, as the Xen pagetables are
|
|
|
|
* set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ... for
|
|
|
|
* the initial domain. For guests using the toolstack, they are in:
|
|
|
|
* [L4], [L3], [L2], [L1], [L1], order .. So for dom0 we can only
|
|
|
|
* rip out the [L4] (pgd), but for guests we shave off three pages.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < ARRAY_SIZE(addr); i++)
|
|
|
|
check_pt_base(&pt_base, &pt_end, addr[i]);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2012-07-26 16:00:56 +00:00
|
|
|
/* Our (by three pages) smaller Xen pagetable that we are using */
|
|
|
|
memblock_reserve(PFN_PHYS(pt_base), (pt_end - pt_base) * PAGE_SIZE);
|
2012-07-26 16:47:40 +00:00
|
|
|
/* Revector the xen_start_info */
|
|
|
|
xen_start_info = (struct start_info *)__va(__pa(xen_start_info));
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
#else /* !CONFIG_X86_64 */
|
2010-11-24 12:09:41 +00:00
|
|
|
static RESERVE_BRK_ARRAY(pmd_t, initial_kernel_pmd, PTRS_PER_PMD);
|
|
|
|
static RESERVE_BRK_ARRAY(pmd_t, swapper_kernel_pmd, PTRS_PER_PMD);
|
|
|
|
|
2011-05-12 21:19:53 +00:00
|
|
|
static void __init xen_write_cr3_init(unsigned long cr3)
|
2010-11-24 12:09:41 +00:00
|
|
|
{
|
|
|
|
unsigned long pfn = PFN_DOWN(__pa(swapper_pg_dir));
|
|
|
|
|
|
|
|
BUG_ON(read_cr3() != __pa(initial_page_table));
|
|
|
|
BUG_ON(cr3 != __pa(swapper_pg_dir));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We are switching to swapper_pg_dir for the first time (from
|
|
|
|
* initial_page_table) and therefore need to mark that page
|
|
|
|
* read-only and then pin it.
|
|
|
|
*
|
|
|
|
* Xen disallows sharing of kernel PMDs for PAE
|
|
|
|
* guests. Therefore we must copy the kernel PMD from
|
|
|
|
* initial_page_table into a new kernel PMD to be used in
|
|
|
|
* swapper_pg_dir.
|
|
|
|
*/
|
|
|
|
swapper_kernel_pmd =
|
|
|
|
extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);
|
2012-07-26 15:57:04 +00:00
|
|
|
copy_page(swapper_kernel_pmd, initial_kernel_pmd);
|
2010-11-24 12:09:41 +00:00
|
|
|
swapper_pg_dir[KERNEL_PGD_BOUNDARY] =
|
|
|
|
__pgd(__pa(swapper_kernel_pmd) | _PAGE_PRESENT);
|
|
|
|
set_page_prot(swapper_kernel_pmd, PAGE_KERNEL_RO);
|
|
|
|
|
|
|
|
set_page_prot(swapper_pg_dir, PAGE_KERNEL_RO);
|
|
|
|
xen_write_cr3(cr3);
|
|
|
|
pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE, pfn);
|
|
|
|
|
|
|
|
pin_pagetable_pfn(MMUEXT_UNPIN_TABLE,
|
|
|
|
PFN_DOWN(__pa(initial_page_table)));
|
|
|
|
set_page_prot(initial_page_table, PAGE_KERNEL);
|
|
|
|
set_page_prot(initial_kernel_pmd, PAGE_KERNEL);
|
|
|
|
|
|
|
|
pv_mmu_ops.write_cr3 = &xen_write_cr3;
|
|
|
|
}
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2012-06-29 02:47:35 +00:00
|
|
|
void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
|
|
|
pmd_t *kernel_pmd;
|
|
|
|
|
2010-11-24 12:09:41 +00:00
|
|
|
initial_kernel_pmd =
|
|
|
|
extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);
|
2010-08-26 23:16:28 +00:00
|
|
|
|
2011-06-03 09:51:34 +00:00
|
|
|
max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->pt_base) +
|
|
|
|
xen_start_info->nr_pt_frames * PAGE_SIZE +
|
|
|
|
512*1024);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
kernel_pmd = m2v(pgd[KERNEL_PGD_BOUNDARY].pgd);
|
2012-07-26 15:57:04 +00:00
|
|
|
copy_page(initial_kernel_pmd, kernel_pmd);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2010-11-24 12:09:41 +00:00
|
|
|
xen_map_identity_early(initial_kernel_pmd, max_pfn);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2012-07-26 15:57:04 +00:00
|
|
|
copy_page(initial_page_table, pgd);
|
2010-11-24 12:09:41 +00:00
|
|
|
initial_page_table[KERNEL_PGD_BOUNDARY] =
|
|
|
|
__pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2010-11-24 12:09:41 +00:00
|
|
|
set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
|
|
|
|
set_page_prot(initial_page_table, PAGE_KERNEL_RO);
|
2009-01-28 22:35:01 +00:00
|
|
|
set_page_prot(empty_zero_page, PAGE_KERNEL_RO);
|
|
|
|
|
|
|
|
pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
|
|
|
|
|
2010-11-24 12:09:41 +00:00
|
|
|
pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
|
|
|
|
PFN_DOWN(__pa(initial_page_table)));
|
|
|
|
xen_write_cr3(__pa(initial_page_table));
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2011-07-12 09:16:06 +00:00
|
|
|
memblock_reserve(__pa(xen_start_info->pt_base),
|
2012-01-08 02:27:38 +00:00
|
|
|
xen_start_info->nr_pt_frames * PAGE_SIZE);
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
#endif /* CONFIG_X86_64 */
|
|
|
|
|
2010-09-03 13:55:16 +00:00
|
|
|
static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss;
|
|
|
|
|
2009-04-09 17:55:33 +00:00
|
|
|
static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
|
|
|
pte_t pte;
|
|
|
|
|
|
|
|
phys >>= PAGE_SHIFT;
|
|
|
|
|
|
|
|
switch (idx) {
|
|
|
|
case FIX_BTMAP_END ... FIX_BTMAP_BEGIN:
|
2013-04-10 19:24:22 +00:00
|
|
|
case FIX_RO_IDT:
|
2009-01-28 22:35:01 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
case FIX_WP_TEST:
|
|
|
|
case FIX_VDSO:
|
|
|
|
# ifdef CONFIG_HIGHMEM
|
|
|
|
case FIX_KMAP_BEGIN ... FIX_KMAP_END:
|
|
|
|
# endif
|
|
|
|
#else
|
|
|
|
case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
|
2011-08-03 13:31:52 +00:00
|
|
|
case VVAR_PAGE:
|
2009-01-28 22:35:01 +00:00
|
|
|
#endif
|
2009-03-08 07:48:41 +00:00
|
|
|
case FIX_TEXT_POKE0:
|
|
|
|
case FIX_TEXT_POKE1:
|
|
|
|
/* All local page mappings */
|
2009-01-28 22:35:01 +00:00
|
|
|
pte = pfn_pte(phys, prot);
|
|
|
|
break;
|
|
|
|
|
2010-09-03 13:55:16 +00:00
|
|
|
#ifdef CONFIG_X86_LOCAL_APIC
|
|
|
|
case FIX_APIC_BASE: /* maps dummy local APIC */
|
|
|
|
pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
|
|
|
|
break;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_IO_APIC
|
|
|
|
case FIX_IO_APIC_BASE_0 ... FIX_IO_APIC_BASE_END:
|
|
|
|
/*
|
|
|
|
* We just don't map the IO APIC - all access is via
|
|
|
|
* hypercalls. Keep the address in the pte for reference.
|
|
|
|
*/
|
2012-04-16 17:53:40 +00:00
|
|
|
pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
|
2010-09-03 13:55:16 +00:00
|
|
|
break;
|
|
|
|
#endif
|
|
|
|
|
2010-02-04 22:46:34 +00:00
|
|
|
case FIX_PARAVIRT_BOOTMAP:
|
|
|
|
/* This is an MFN, but it isn't an IO mapping from the
|
|
|
|
IO domain */
|
2009-01-28 22:35:01 +00:00
|
|
|
pte = mfn_pte(phys, prot);
|
|
|
|
break;
|
2010-02-04 22:46:34 +00:00
|
|
|
|
|
|
|
default:
|
|
|
|
/* By default, set_fixmap is used for hardware mappings */
|
|
|
|
pte = mfn_pte(phys, __pgprot(pgprot_val(prot) | _PAGE_IOMAP));
|
|
|
|
break;
|
2009-01-28 22:35:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
__native_set_fixmap(idx, pte);
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
/* Replicate changes to map the vsyscall page into the user
|
|
|
|
pagetable vsyscall mapping. */
|
2011-08-03 13:31:52 +00:00
|
|
|
if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
|
|
|
|
idx == VVAR_PAGE) {
|
2009-01-28 22:35:01 +00:00
|
|
|
unsigned long vaddr = __fix_to_virt(idx);
|
|
|
|
set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2011-05-12 21:19:53 +00:00
|
|
|
static void __init xen_post_allocator_init(void)
|
2009-01-28 22:35:01 +00:00
|
|
|
{
|
|
|
|
pv_mmu_ops.set_pte = xen_set_pte;
|
|
|
|
pv_mmu_ops.set_pmd = xen_set_pmd;
|
|
|
|
pv_mmu_ops.set_pud = xen_set_pud;
|
|
|
|
#if PAGETABLE_LEVELS == 4
|
|
|
|
pv_mmu_ops.set_pgd = xen_set_pgd;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* This will work as long as patching hasn't happened yet
|
|
|
|
(which it hasn't) */
|
|
|
|
pv_mmu_ops.alloc_pte = xen_alloc_pte;
|
|
|
|
pv_mmu_ops.alloc_pmd = xen_alloc_pmd;
|
|
|
|
pv_mmu_ops.release_pte = xen_release_pte;
|
|
|
|
pv_mmu_ops.release_pmd = xen_release_pmd;
|
|
|
|
#if PAGETABLE_LEVELS == 4
|
|
|
|
pv_mmu_ops.alloc_pud = xen_alloc_pud;
|
|
|
|
pv_mmu_ops.release_pud = xen_release_pud;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_64
|
2013-03-22 14:34:28 +00:00
|
|
|
pv_mmu_ops.write_cr3 = &xen_write_cr3;
|
2009-01-28 22:35:01 +00:00
|
|
|
SetPagePinned(virt_to_page(level3_user_vsyscall));
|
|
|
|
#endif
|
|
|
|
xen_mark_init_mm_pinned();
|
|
|
|
}
|
|
|
|
|
2009-02-18 07:46:21 +00:00
|
|
|
static void xen_leave_lazy_mmu(void)
|
|
|
|
{
|
2009-02-21 07:01:26 +00:00
|
|
|
preempt_disable();
|
2009-02-18 07:46:21 +00:00
|
|
|
xen_mc_flush();
|
|
|
|
paravirt_leave_lazy_mmu();
|
2009-02-21 07:01:26 +00:00
|
|
|
preempt_enable();
|
2009-02-18 07:46:21 +00:00
|
|
|
}
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2011-05-12 21:19:53 +00:00
|
|
|
static const struct pv_mmu_ops xen_mmu_ops __initconst = {
|
2009-01-28 22:35:01 +00:00
|
|
|
.read_cr2 = xen_read_cr2,
|
|
|
|
.write_cr2 = xen_write_cr2,
|
|
|
|
|
|
|
|
.read_cr3 = xen_read_cr3,
|
2010-11-24 12:09:41 +00:00
|
|
|
.write_cr3 = xen_write_cr3_init,
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
.flush_tlb_user = xen_flush_tlb,
|
|
|
|
.flush_tlb_kernel = xen_flush_tlb,
|
|
|
|
.flush_tlb_single = xen_flush_tlb_single,
|
|
|
|
.flush_tlb_others = xen_flush_tlb_others,
|
|
|
|
|
|
|
|
.pte_update = paravirt_nop,
|
|
|
|
.pte_update_defer = paravirt_nop,
|
|
|
|
|
|
|
|
.pgd_alloc = xen_pgd_alloc,
|
|
|
|
.pgd_free = xen_pgd_free,
|
|
|
|
|
|
|
|
.alloc_pte = xen_alloc_pte_init,
|
|
|
|
.release_pte = xen_release_pte_init,
|
2009-03-17 20:30:55 +00:00
|
|
|
.alloc_pmd = xen_alloc_pmd_init,
|
|
|
|
.release_pmd = xen_release_pmd_init,
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
.set_pte = xen_set_pte_init,
|
|
|
|
.set_pte_at = xen_set_pte_at,
|
|
|
|
.set_pmd = xen_set_pmd_hyper,
|
|
|
|
|
|
|
|
.ptep_modify_prot_start = __ptep_modify_prot_start,
|
|
|
|
.ptep_modify_prot_commit = __ptep_modify_prot_commit,
|
|
|
|
|
2009-01-28 22:35:07 +00:00
|
|
|
.pte_val = PV_CALLEE_SAVE(xen_pte_val),
|
|
|
|
.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2009-01-28 22:35:07 +00:00
|
|
|
.make_pte = PV_CALLEE_SAVE(xen_make_pte),
|
|
|
|
.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_X86_PAE
|
|
|
|
.set_pte_atomic = xen_set_pte_atomic,
|
|
|
|
.pte_clear = xen_pte_clear,
|
|
|
|
.pmd_clear = xen_pmd_clear,
|
|
|
|
#endif /* CONFIG_X86_PAE */
|
|
|
|
.set_pud = xen_set_pud_hyper,
|
|
|
|
|
2009-01-28 22:35:07 +00:00
|
|
|
.make_pmd = PV_CALLEE_SAVE(xen_make_pmd),
|
|
|
|
.pmd_val = PV_CALLEE_SAVE(xen_pmd_val),
|
2009-01-28 22:35:01 +00:00
|
|
|
|
|
|
|
#if PAGETABLE_LEVELS == 4
|
2009-01-28 22:35:07 +00:00
|
|
|
.pud_val = PV_CALLEE_SAVE(xen_pud_val),
|
|
|
|
.make_pud = PV_CALLEE_SAVE(xen_make_pud),
|
2009-01-28 22:35:01 +00:00
|
|
|
.set_pgd = xen_set_pgd_hyper,
|
|
|
|
|
2009-03-17 20:30:55 +00:00
|
|
|
.alloc_pud = xen_alloc_pmd_init,
|
|
|
|
.release_pud = xen_release_pmd_init,
|
2009-01-28 22:35:01 +00:00
|
|
|
#endif /* PAGETABLE_LEVELS == 4 */
|
|
|
|
|
|
|
|
.activate_mm = xen_activate_mm,
|
|
|
|
.dup_mmap = xen_dup_mmap,
|
|
|
|
.exit_mmap = xen_exit_mmap,
|
|
|
|
|
|
|
|
.lazy_mode = {
|
|
|
|
.enter = paravirt_enter_lazy_mmu,
|
2009-02-18 07:46:21 +00:00
|
|
|
.leave = xen_leave_lazy_mmu,
|
2013-03-23 13:36:36 +00:00
|
|
|
.flush = paravirt_flush_lazy_mmu,
|
2009-01-28 22:35:01 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
.set_fixmap = xen_set_fixmap,
|
|
|
|
};
|
|
|
|
|
2009-08-20 12:30:02 +00:00
|
|
|
void __init xen_init_mmu_ops(void)
|
|
|
|
{
|
2012-08-21 20:22:38 +00:00
|
|
|
x86_init.paging.pagetable_init = xen_pagetable_init;
|
2009-08-20 12:30:02 +00:00
|
|
|
pv_mmu_ops = xen_mmu_ops;
|
2010-03-26 22:37:50 +00:00
|
|
|
|
2010-09-03 13:55:16 +00:00
|
|
|
memset(dummy_mapping, 0xff, PAGE_SIZE);
|
2009-08-20 12:30:02 +00:00
|
|
|
}
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2009-02-09 20:05:46 +00:00
|
|
|
/* Protected by xen_reservation_lock. */
|
|
|
|
#define MAX_CONTIG_ORDER 9 /* 2MB */
|
|
|
|
static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
|
|
|
|
|
|
|
|
#define VOID_PTE (mfn_pte(0, __pgprot(0)))
|
|
|
|
static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
|
|
|
|
unsigned long *in_frames,
|
|
|
|
unsigned long *out_frames)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct multicall_space mcs;
|
|
|
|
|
|
|
|
xen_mc_batch();
|
|
|
|
for (i = 0; i < (1UL<<order); i++, vaddr += PAGE_SIZE) {
|
|
|
|
mcs = __xen_mc_entry(0);
|
|
|
|
|
|
|
|
if (in_frames)
|
|
|
|
in_frames[i] = virt_to_mfn(vaddr);
|
|
|
|
|
|
|
|
MULTI_update_va_mapping(mcs.mc, vaddr, VOID_PTE, 0);
|
2011-01-19 01:09:41 +00:00
|
|
|
__set_phys_to_machine(virt_to_pfn(vaddr), INVALID_P2M_ENTRY);
|
2009-02-09 20:05:46 +00:00
|
|
|
|
|
|
|
if (out_frames)
|
|
|
|
out_frames[i] = virt_to_pfn(vaddr);
|
|
|
|
}
|
|
|
|
xen_mc_issue(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update the pfn-to-mfn mappings for a virtual address range, either to
|
|
|
|
* point to an array of mfns, or contiguously from a single starting
|
|
|
|
* mfn.
|
|
|
|
*/
|
|
|
|
static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,
|
|
|
|
unsigned long *mfns,
|
|
|
|
unsigned long first_mfn)
|
|
|
|
{
|
|
|
|
unsigned i, limit;
|
|
|
|
unsigned long mfn;
|
|
|
|
|
|
|
|
xen_mc_batch();
|
|
|
|
|
|
|
|
limit = 1u << order;
|
|
|
|
for (i = 0; i < limit; i++, vaddr += PAGE_SIZE) {
|
|
|
|
struct multicall_space mcs;
|
|
|
|
unsigned flags;
|
|
|
|
|
|
|
|
mcs = __xen_mc_entry(0);
|
|
|
|
if (mfns)
|
|
|
|
mfn = mfns[i];
|
|
|
|
else
|
|
|
|
mfn = first_mfn + i;
|
|
|
|
|
|
|
|
if (i < (limit - 1))
|
|
|
|
flags = 0;
|
|
|
|
else {
|
|
|
|
if (order == 0)
|
|
|
|
flags = UVMF_INVLPG | UVMF_ALL;
|
|
|
|
else
|
|
|
|
flags = UVMF_TLB_FLUSH | UVMF_ALL;
|
|
|
|
}
|
|
|
|
|
|
|
|
MULTI_update_va_mapping(mcs.mc, vaddr,
|
|
|
|
mfn_pte(mfn, PAGE_KERNEL), flags);
|
|
|
|
|
|
|
|
set_phys_to_machine(virt_to_pfn(vaddr), mfn);
|
|
|
|
}
|
|
|
|
|
|
|
|
xen_mc_issue(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Perform the hypercall to exchange a region of our pfns to point to
|
|
|
|
* memory with the required contiguous alignment. Takes the pfns as
|
|
|
|
* input, and populates mfns as output.
|
|
|
|
*
|
|
|
|
* Returns a success code indicating whether the hypervisor was able to
|
|
|
|
* satisfy the request or not.
|
|
|
|
*/
|
|
|
|
static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,
|
|
|
|
unsigned long *pfns_in,
|
|
|
|
unsigned long extents_out,
|
|
|
|
unsigned int order_out,
|
|
|
|
unsigned long *mfns_out,
|
|
|
|
unsigned int address_bits)
|
|
|
|
{
|
|
|
|
long rc;
|
|
|
|
int success;
|
|
|
|
|
|
|
|
struct xen_memory_exchange exchange = {
|
|
|
|
.in = {
|
|
|
|
.nr_extents = extents_in,
|
|
|
|
.extent_order = order_in,
|
|
|
|
.extent_start = pfns_in,
|
|
|
|
.domid = DOMID_SELF
|
|
|
|
},
|
|
|
|
.out = {
|
|
|
|
.nr_extents = extents_out,
|
|
|
|
.extent_order = order_out,
|
|
|
|
.extent_start = mfns_out,
|
|
|
|
.address_bits = address_bits,
|
|
|
|
.domid = DOMID_SELF
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
BUG_ON(extents_in << order_in != extents_out << order_out);
|
|
|
|
|
|
|
|
rc = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
|
|
|
|
success = (exchange.nr_exchanged == extents_in);
|
|
|
|
|
|
|
|
BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
|
|
|
|
BUG_ON(success && (rc != 0));
|
|
|
|
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
|
|
|
|
unsigned int address_bits)
|
|
|
|
{
|
|
|
|
unsigned long *in_frames = discontig_frames, out_frame;
|
|
|
|
unsigned long flags;
|
|
|
|
int success;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Currently an auto-translated guest will not perform I/O, nor will
|
|
|
|
* it require PAE page directories below 4GB. Therefore any calls to
|
|
|
|
* this function are redundant and can be ignored.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (xen_feature(XENFEAT_auto_translated_physmap))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (unlikely(order > MAX_CONTIG_ORDER))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
memset((void *) vstart, 0, PAGE_SIZE << order);
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xen_reservation_lock, flags);
|
|
|
|
|
|
|
|
/* 1. Zap current PTEs, remembering MFNs. */
|
|
|
|
xen_zap_pfn_range(vstart, order, in_frames, NULL);
|
|
|
|
|
|
|
|
/* 2. Get a new contiguous memory extent. */
|
|
|
|
out_frame = virt_to_pfn(vstart);
|
|
|
|
success = xen_exchange_memory(1UL << order, 0, in_frames,
|
|
|
|
1, order, &out_frame,
|
|
|
|
address_bits);
|
|
|
|
|
|
|
|
/* 3. Map the new extent in place of old pages. */
|
|
|
|
if (success)
|
|
|
|
xen_remap_exchanged_ptes(vstart, order, NULL, out_frame);
|
|
|
|
else
|
|
|
|
xen_remap_exchanged_ptes(vstart, order, in_frames, 0);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&xen_reservation_lock, flags);
|
|
|
|
|
|
|
|
return success ? 0 : -ENOMEM;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
|
|
|
|
|
|
|
|
void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
|
|
|
|
{
|
|
|
|
unsigned long *out_frames = discontig_frames, in_frame;
|
|
|
|
unsigned long flags;
|
|
|
|
int success;
|
|
|
|
|
|
|
|
if (xen_feature(XENFEAT_auto_translated_physmap))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (unlikely(order > MAX_CONTIG_ORDER))
|
|
|
|
return;
|
|
|
|
|
|
|
|
memset((void *) vstart, 0, PAGE_SIZE << order);
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xen_reservation_lock, flags);
|
|
|
|
|
|
|
|
/* 1. Find start MFN of contiguous extent. */
|
|
|
|
in_frame = virt_to_mfn(vstart);
|
|
|
|
|
|
|
|
/* 2. Zap current PTEs. */
|
|
|
|
xen_zap_pfn_range(vstart, order, NULL, out_frames);
|
|
|
|
|
|
|
|
/* 3. Do the exchange for non-contiguous MFNs. */
|
|
|
|
success = xen_exchange_memory(1, order, &in_frame, 1UL << order,
|
|
|
|
0, out_frames, 0);
|
|
|
|
|
|
|
|
/* 4. Map new pages in place of old pages. */
|
|
|
|
if (success)
|
|
|
|
xen_remap_exchanged_ptes(vstart, order, out_frames, 0);
|
|
|
|
else
|
|
|
|
xen_remap_exchanged_ptes(vstart, order, NULL, in_frame);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&xen_reservation_lock, flags);
|
2009-08-20 12:30:02 +00:00
|
|
|
}
|
2009-02-09 20:05:46 +00:00
|
|
|
EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
|
2009-01-28 22:35:01 +00:00
|
|
|
|
2010-07-29 13:37:48 +00:00
|
|
|
#ifdef CONFIG_XEN_PVHVM
|
2012-10-01 19:18:01 +00:00
|
|
|
#ifdef CONFIG_PROC_VMCORE
|
|
|
|
/*
|
|
|
|
* This function is used in two contexts:
|
|
|
|
* - the kdump kernel has to check whether a pfn of the crashed kernel
|
|
|
|
* was a ballooned page. vmcore is using this function to decide
|
|
|
|
* whether to access a pfn of the crashed kernel.
|
|
|
|
* - the kexec kernel has to check whether a pfn was ballooned by the
|
|
|
|
* previous kernel. If the pfn is ballooned, handle it properly.
|
|
|
|
* Returns 0 if the pfn is not backed by a RAM page, the caller may
|
|
|
|
* handle the pfn special in this case.
|
|
|
|
*/
|
|
|
|
static int xen_oldmem_pfn_is_ram(unsigned long pfn)
|
|
|
|
{
|
|
|
|
struct xen_hvm_get_mem_type a = {
|
|
|
|
.domid = DOMID_SELF,
|
|
|
|
.pfn = pfn,
|
|
|
|
};
|
|
|
|
int ram;
|
|
|
|
|
|
|
|
if (HYPERVISOR_hvm_op(HVMOP_get_mem_type, &a))
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
switch (a.mem_type) {
|
|
|
|
case HVMMEM_mmio_dm:
|
|
|
|
ram = 0;
|
|
|
|
break;
|
|
|
|
case HVMMEM_ram_rw:
|
|
|
|
case HVMMEM_ram_ro:
|
|
|
|
default:
|
|
|
|
ram = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ram;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-06-17 13:22:52 +00:00
|
|
|
static void xen_hvm_exit_mmap(struct mm_struct *mm)
|
|
|
|
{
|
|
|
|
struct xen_hvm_pagetable_dying a;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
a.domid = DOMID_SELF;
|
|
|
|
a.gpa = __pa(mm->pgd);
|
|
|
|
rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
|
|
|
|
WARN_ON_ONCE(rc < 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int is_pagetable_dying_supported(void)
|
|
|
|
{
|
|
|
|
struct xen_hvm_pagetable_dying a;
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
a.domid = DOMID_SELF;
|
|
|
|
a.gpa = 0x00;
|
|
|
|
rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
|
|
|
|
if (rc < 0) {
|
|
|
|
printk(KERN_DEBUG "HVMOP_pagetable_dying not supported\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init xen_hvm_init_mmu_ops(void)
|
|
|
|
{
|
|
|
|
if (is_pagetable_dying_supported())
|
|
|
|
pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap;
|
2012-10-01 19:18:01 +00:00
|
|
|
#ifdef CONFIG_PROC_VMCORE
|
|
|
|
register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram);
|
|
|
|
#endif
|
2010-06-17 13:22:52 +00:00
|
|
|
}
|
2010-07-29 13:37:48 +00:00
|
|
|
#endif
|
2010-06-17 13:22:52 +00:00
|
|
|
|
2009-05-21 09:09:46 +00:00
|
|
|
#define REMAP_BATCH_SIZE 16
|
|
|
|
|
|
|
|
struct remap_data {
|
|
|
|
unsigned long mfn;
|
|
|
|
pgprot_t prot;
|
|
|
|
struct mmu_update *mmu_update;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
|
|
|
|
unsigned long addr, void *data)
|
|
|
|
{
|
|
|
|
struct remap_data *rmd = data;
|
|
|
|
pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot));
|
|
|
|
|
2010-12-22 21:09:40 +00:00
|
|
|
rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
|
2009-05-21 09:09:46 +00:00
|
|
|
rmd->mmu_update->val = pte_val_ma(pte);
|
|
|
|
rmd->mmu_update++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
|
|
|
|
unsigned long addr,
|
2012-10-16 16:19:15 +00:00
|
|
|
xen_pfn_t mfn, int nr,
|
2012-10-17 20:37:49 +00:00
|
|
|
pgprot_t prot, unsigned domid,
|
|
|
|
struct page **pages)
|
|
|
|
|
2009-05-21 09:09:46 +00:00
|
|
|
{
|
|
|
|
struct remap_data rmd;
|
|
|
|
struct mmu_update mmu_update[REMAP_BATCH_SIZE];
|
|
|
|
int batch;
|
|
|
|
unsigned long range;
|
|
|
|
int err = 0;
|
|
|
|
|
2012-08-22 16:20:16 +00:00
|
|
|
if (xen_feature(XENFEAT_auto_translated_physmap))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2009-05-21 09:09:46 +00:00
|
|
|
prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
|
|
|
|
|
mm: kill vma flag VM_RESERVED and mm->reserved_vm counter
A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
currently it lost original meaning but still has some effects:
| effect | alternative flags
-+------------------------+---------------------------------------------
1| account as reserved_vm | VM_IO
2| skip in core dump | VM_IO, VM_DONTDUMP
3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
4| do not mlock | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
This patch removes reserved_vm counter from mm_struct. Seems like nobody
cares about it, it does not exported into userspace directly, it only
reduces total_vm showed in proc.
Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
[akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Eric Paris <eparis@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: Matt Helsley <matthltc@us.ibm.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Venkatesh Pallipadi <venki@google.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-08 23:29:02 +00:00
|
|
|
BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
|
2009-05-21 09:09:46 +00:00
|
|
|
|
|
|
|
rmd.mfn = mfn;
|
|
|
|
rmd.prot = prot;
|
|
|
|
|
|
|
|
while (nr) {
|
|
|
|
batch = min(REMAP_BATCH_SIZE, nr);
|
|
|
|
range = (unsigned long)batch << PAGE_SHIFT;
|
|
|
|
|
|
|
|
rmd.mmu_update = mmu_update;
|
|
|
|
err = apply_to_page_range(vma->vm_mm, addr, range,
|
|
|
|
remap_area_mfn_pte_fn, &rmd);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
2012-08-30 12:58:11 +00:00
|
|
|
err = HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid);
|
|
|
|
if (err < 0)
|
2009-05-21 09:09:46 +00:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
nr -= batch;
|
|
|
|
addr += range;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
out:
|
|
|
|
|
2012-10-31 16:38:31 +00:00
|
|
|
xen_flush_tlb_all();
|
2009-05-21 09:09:46 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
|
2012-10-17 20:37:49 +00:00
|
|
|
|
|
|
|
/* Returns: 0 success */
|
|
|
|
int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
|
|
|
|
int numpgs, struct page **pages)
|
|
|
|
{
|
|
|
|
if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
|