From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
boris.ostrovsky@oracle.com, stefano.stabellini@eu.citrix.com,
david.vrabel@citrix.com
Cc: hpa@zytor.com, Mukesh Rathor <mukesh.rathor@oracle.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [PATCH v13 07/19] xen/pvh: MMU changes for PVH (v2)
Date: Fri, 3 Jan 2014 14:38:24 -0500 [thread overview]
Message-ID: <1388777916-1328-8-git-send-email-konrad.wilk@oracle.com> (raw)
In-Reply-To: <1388777916-1328-1-git-send-email-konrad.wilk@oracle.com>
From: Mukesh Rathor <mukesh.rathor@oracle.com>
.. which are surprinsingly small compared to the amount for PV code.
PVH uses mostly native mmu ops, we leave the generic (native_*) for
the majority and just overwrite the baremetal with the ones we need.
At startup, we are running with pre-allocated page-tables
courtesy of the tool-stack. But we still need to graft them
in the Linux initial pagetables. However there is no need to
unpin/pin and change them to R/O or R/W.
Note that the xen_pagetable_init due to 7836fec9d0994cc9c9150c5a33f0eb0eb08a335a
"xen/mmu/p2m: Refactor the xen_pagetable_init code." does not
need any changes - we just need to make sure that xen_post_allocator_init
does not alter the pvops from the default native one.
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/mmu.c | 81 +++++++++++++++++++++++++++++++-----------------------
1 file changed, 46 insertions(+), 35 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 9d74249..490ddb3 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1757,6 +1757,10 @@ static void set_page_prot_flags(void *addr, pgprot_t prot, unsigned long flags)
unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
pte_t pte = pfn_pte(pfn, prot);
+ /* For PVH no need to set R/O or R/W to pin them or unpin them. */
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return;
+
if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, flags))
BUG();
}
@@ -1867,6 +1871,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
* 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.
+ * NOTE: for PVH, the page tables are native.
*/
void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
{
@@ -1888,17 +1893,18 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
/* Zap identity mapping */
init_level4_pgt[0] = __pgd(0);
- /* Pre-constructed entries are in pfn, so convert to mfn */
- /* L4[272] -> level3_ident_pgt
- * L4[511] -> level3_kernel_pgt */
- convert_pfn_mfn(init_level4_pgt);
-
- /* L3_i[0] -> level2_ident_pgt */
- convert_pfn_mfn(level3_ident_pgt);
- /* L3_k[510] -> level2_kernel_pgt
- * L3_i[511] -> level2_fixmap_pgt */
- convert_pfn_mfn(level3_kernel_pgt);
-
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ /* Pre-constructed entries are in pfn, so convert to mfn */
+ /* L4[272] -> level3_ident_pgt
+ * L4[511] -> level3_kernel_pgt */
+ convert_pfn_mfn(init_level4_pgt);
+
+ /* L3_i[0] -> level2_ident_pgt */
+ convert_pfn_mfn(level3_ident_pgt);
+ /* L3_k[510] -> level2_kernel_pgt
+ * L3_i[511] -> level2_fixmap_pgt */
+ convert_pfn_mfn(level3_kernel_pgt);
+ }
/* We get [511][511] and have Xen's version of level2_kernel_pgt */
l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);
@@ -1922,31 +1928,33 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
copy_page(level2_fixmap_pgt, l2);
/* Note that we don't do anything with level1_fixmap_pgt which
* we don't need. */
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ /* 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);
+ set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
+ 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)));
- /* 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);
- set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
- 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();
- __xen_write_cr3(true, __pa(init_level4_pgt));
- xen_mc_issue(PARAVIRT_LAZY_CPU);
+ /*
+ * 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();
+ __xen_write_cr3(true, __pa(init_level4_pgt));
+ xen_mc_issue(PARAVIRT_LAZY_CPU);
+ } else
+ native_write_cr3(__pa(init_level4_pgt));
/* 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
@@ -2107,6 +2115,9 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
static void __init xen_post_allocator_init(void)
{
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return;
+
pv_mmu_ops.set_pte = xen_set_pte;
pv_mmu_ops.set_pmd = xen_set_pmd;
pv_mmu_ops.set_pud = xen_set_pud;
--
1.8.3.1
next prev parent reply other threads:[~2014-01-03 20:30 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 19:38 [PATCH v13] Linux Xen PVH support (v13) Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 01/19] xen/p2m: Check for auto-xlat when doing mfn_to_local_pfn Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 02/19] xen/pvh/x86: Define what an PVH guest is (v3) Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 03/19] xen/pvh: Early bootup changes in PV code (v4) Konrad Rzeszutek Wilk
2014-01-05 17:49 ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 04/19] xen/pvh: Don't setup P2M tree Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 05/19] xen/mmu/p2m: Refactor the xen_pagetable_init code (v2) Konrad Rzeszutek Wilk
2014-01-05 17:51 ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 06/19] xen/mmu: Cleanup xen_pagetable_p2m_copy a bit Konrad Rzeszutek Wilk
2014-01-05 17:56 ` Stefano Stabellini
2014-01-03 19:38 ` Konrad Rzeszutek Wilk [this message]
2014-01-03 19:38 ` [PATCH v13 08/19] xen/pvh/mmu: Use PV TLB instead of native Konrad Rzeszutek Wilk
2014-01-05 18:11 ` Stefano Stabellini
2014-01-05 19:41 ` Konrad Rzeszutek Wilk
2014-01-06 11:33 ` Stefano Stabellini
2014-01-06 14:59 ` Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 09/19] xen/pvh: Setup up shared_info Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 10/19] xen/pvh: Load GDT/GS in early PV bootup code for BSP Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 11/19] xen/pvh: Secondary VCPU bringup (non-bootup CPUs) Konrad Rzeszutek Wilk
2014-01-06 10:52 ` David Vrabel
2014-01-06 15:03 ` Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 12/19] xen/pvh: Update E820 to work with PVH (v2) Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 13/19] xen/pvh: Piggyback on PVHVM for event channels (v2) Konrad Rzeszutek Wilk
2014-01-05 18:15 ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 14/19] xen/grants: Remove gnttab_max_grant_frames dependency on gnttab_init Konrad Rzeszutek Wilk
2014-01-05 18:16 ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 15/19] xen/grant-table: Refactor gnttab_init Konrad Rzeszutek Wilk
2014-01-05 18:18 ` Stefano Stabellini
2014-01-05 19:33 ` Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 16/19] xen/grant: Implement an grant frame array struct (v2) Konrad Rzeszutek Wilk
2014-01-05 18:38 ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 17/19] xen/pvh: Piggyback on PVHVM for grant driver (v4) Konrad Rzeszutek Wilk
2014-01-05 18:20 ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 18/19] xen/pvh: Piggyback on PVHVM XenBus Konrad Rzeszutek Wilk
2014-01-05 17:54 ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 19/19] xen/pvh: Support ParaVirtualized Hardware extensions (v3) Konrad Rzeszutek Wilk
2014-01-06 10:55 ` [PATCH v13] Linux Xen PVH support (v13) David Vrabel
2014-01-06 14:53 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1388777916-1328-8-git-send-email-konrad.wilk@oracle.com \
--to=konrad.wilk@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mukesh.rathor@oracle.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).