All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: "Julien Grall" <jgrall@amazon.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Elias El Yandouzi" <eliasely@amazon.com>,
	"Alejandro Vallejo" <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 06/15] xen/x86: Add support for the PMAP
Date: Wed,  8 Jan 2025 15:18:13 +0000	[thread overview]
Message-ID: <20250108151822.16030-7-alejandro.vallejo@cloud.com> (raw)
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>

From: Julien Grall <jgrall@amazon.com>

PMAP will be used in a follow-up patch to bootstrap map domain
page infrastructure -- we need some way to map pages to setup the
mapcache without a direct map.

The functions pmap_{map, unmap} open code {set, clear}_fixmap to break
the loop.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * No changes.

v3->v4:
  * Select PMAP KConfig option iff ONDEMAND_DIRECTMAP is used

v2->v3:
  * No changes.

v1->v2:
  * Declare PMAP entries earlier in fixed_addresses
  * Reword the commit message

    The PMAP infrastructure was upstream separately for Arm since
    Hongyan sent the secret-free hypervisor series. So this is a new
    patch to plumb the feature on x86.
---
 xen/arch/x86/include/asm/fixmap.h |  6 ++++++
 xen/arch/x86/include/asm/pmap.h   | 35 +++++++++++++++++++++++++++++++
 xen/common/Kconfig                |  1 +
 3 files changed, 42 insertions(+)
 create mode 100644 xen/arch/x86/include/asm/pmap.h

diff --git a/xen/arch/x86/include/asm/fixmap.h b/xen/arch/x86/include/asm/fixmap.h
index 516ec3fa6c95..80b7b74fd816 100644
--- a/xen/arch/x86/include/asm/fixmap.h
+++ b/xen/arch/x86/include/asm/fixmap.h
@@ -21,6 +21,8 @@
 
 #include <xen/acpi.h>
 #include <xen/pfn.h>
+#include <xen/pmap.h>
+
 #include <asm/apicdef.h>
 #include <asm/msi.h>
 #include <acpi/apei.h>
@@ -53,6 +55,10 @@ enum fixed_addresses {
     FIX_PV_CONSOLE,
     FIX_XEN_SHARED_INFO,
 #endif /* CONFIG_XEN_GUEST */
+#ifdef CONFIG_HAS_PMAP
+    FIX_PMAP_BEGIN,
+    FIX_PMAP_END = FIX_PMAP_BEGIN + NUM_FIX_PMAP,
+#endif
     /* Everything else should go further down. */
     FIX_APIC_BASE,
     FIX_IO_APIC_BASE_0,
diff --git a/xen/arch/x86/include/asm/pmap.h b/xen/arch/x86/include/asm/pmap.h
new file mode 100644
index 000000000000..1b3b729b90b2
--- /dev/null
+++ b/xen/arch/x86/include/asm/pmap.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_PMAP_H__
+#define __ASM_PMAP_H__
+
+#include <asm/fixmap.h>
+
+static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
+{
+    unsigned long linear = (unsigned long)fix_to_virt(slot);
+    l1_pgentry_t *pl1e = &l1_fixmap[l1_table_offset(linear)];
+
+    BUILD_BUG_ON(FIX_APIC_BASE - 1 > L1_PAGETABLE_ENTRIES - 1);
+    ASSERT(!(l1e_get_flags(*pl1e) & _PAGE_PRESENT));
+
+    l1e_write(pl1e, l1e_from_mfn(mfn, PAGE_HYPERVISOR));
+}
+
+static inline void arch_pmap_unmap(unsigned int slot)
+{
+    unsigned long linear = (unsigned long)fix_to_virt(slot);
+    l1_pgentry_t *pl1e = &l1_fixmap[l1_table_offset(linear)];
+
+    l1e_write(pl1e, l1e_empty());
+    flush_tlb_one_local(linear);
+}
+
+#endif /* __ASM_PMAP_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 1ee498a3e9a7..5b22b09a4fbc 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -220,6 +220,7 @@ config SPECULATIVE_HARDEN_LOCK
 config ONDEMAND_DIRECTMAP
 	bool "On-Demand Directmap"
 	depends on HAS_ONDEMAND_DIRECTMAP
+	select HAS_PMAP
 	help
 	  Contemporary processors may use speculative execution as a
 	  performance optimisation, but this can potentially be abused by an
-- 
2.47.1



  parent reply	other threads:[~2025-01-08 15:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-08 15:18 [PATCH v5 00/15] Remove the directmap Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 01/15] x86: Create per-domain mapping for guest_root_pt Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 02/15] x86/pv: Use copy_domain_page() to manage domheap pages during initrd relocation Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 03/15] x86/pv: Rewrite how building PV dom0 handles domheap mappings Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 04/15] x86: Initialize mapcache for PV, HVM, and idle domains Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 05/15] x86: Add a boot option to enable and disable the direct map Alejandro Vallejo
2025-01-08 15:18 ` Alejandro Vallejo [this message]
2025-01-08 15:18 ` [PATCH v5 07/15] x86/domain_page: Remove the fast paths when mfn is not in the directmap Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 08/15] xen/page_alloc: Add a path for xenheap when there is no direct map Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 09/15] x86/setup: Leave early boot slightly earlier Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 10/15] xen/page_alloc: vmap heap nodes when they are outside the direct map Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 11/15] x86/setup: Do not create valid mappings when directmap=no Alejandro Vallejo
2025-12-04 11:04   ` Roger Pau Monné
2025-01-08 15:18 ` [PATCH v5 12/15] xen/arm64: mm: Use per-pCPU page-tables Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 13/15] xen/arm32: Hardwire zeroeth_table_offset to 0 on ARM_32 Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 14/15] xen/arm64: Implement a mapcache for arm64 Alejandro Vallejo
2025-01-08 15:18 ` [PATCH v5 15/15] xen/arm64: Allow the admin to enable/disable the directmap Alejandro Vallejo
2025-01-08 15:30 ` [PATCH v5 00/15] Remove " Alejandro Vallejo
2025-02-06 14:55 ` Alejandro Vallejo
2025-02-06 15:06   ` Roger Pau Monné

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=20250108151822.16030-7-alejandro.vallejo@cloud.com \
    --to=alejandro.vallejo@cloud.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=eliasely@amazon.com \
    --cc=jbeulich@suse.com \
    --cc=jgrall@amazon.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.