[Xen-devel] [PATCH for-4.13 v2 0/2] Errata implementation and doc update

[Xen-devel] [PATCH for-4.13 v2 0/2] Errata implementation and doc update

[Julien Grall]

Hi all,

The two patches are not related but the second one dependends on the first
one. So I decided to merge them together.

Cheers,

Julien Grall (2):
  xen/arm: Implement workaround for Cortex A-57 and Cortex A72 AT
    speculate
  docs: Replace all instance of ARM by Arm

 SUPPORT.md                                 | 50 +++++++++++++++---------------
 docs/INDEX                                 |  6 ++--
 docs/features/livepatch.pandoc             |  2 +-
 docs/features/sched_rtds.pandoc            |  2 +-
 docs/hypervisor-guide/code-coverage.rst    |  2 +-
 docs/man/xl.cfg.5.pod.in                   |  8 ++---
 docs/misc/arm/booting.txt                  | 10 +++---
 docs/misc/arm/device-tree/guest.txt        |  4 +--
 docs/misc/arm/early-printk.txt             |  2 +-
 docs/misc/arm/silicon-errata.txt           | 24 +++++++-------
 docs/misc/console.txt                      |  2 +-
 docs/misc/efi.pandoc                       |  2 +-
 docs/misc/livepatch.pandoc                 |  8 ++---
 docs/misc/xen-command-line.pandoc          | 22 ++++++-------
 docs/process/xen-release-management.pandoc |  2 +-
 docs/specs/libxc-migration-stream.pandoc   |  6 ++--
 docs/specs/libxl-migration-stream.pandoc   |  2 +-
 xen/arch/arm/cpuerrata.c                   | 10 ++++++
 18 files changed, 88 insertions(+), 76 deletions(-)

-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13 v2 1/2] xen/arm: Implement workaround for Cortex A-57 and Cortex A72 AT speculate

[Julien Grall]

Both Cortex-A57 (erratum 1319537) and Cortex-A72 (erratum 1319367) can
end with corrupt TLBs if they speculate an AT instruction while S1/S2
system registers in inconsistent state.

The workaround is the same as for Cortex A-76 implemented by commit
a18be06aca "xen/arm: Implement workaround for Cortex-A76 erratum 1165522",
so it is only necessary to plumb in the cpuerrata framework.

Signed-off-by: Julien Grall <julien.grall@arm.com>

---
    Changes in v2:
        - Add missing |
---
 docs/misc/arm/silicon-errata.txt |  2 ++
 xen/arch/arm/cpuerrata.c         | 10 ++++++++++
 2 files changed, 12 insertions(+)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 6cd1366f15..11e5a9dcec 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -48,5 +48,7 @@ stable hypervisors.
 | ARM            | Cortex-A57      | #852523         | N/A                     |
 | ARM            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |
 | ARM            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |
+| ARM            | Cortex-A57      | #1319537        | N/A                     |
+| ARM            | Cortex-A72      | #1319367        | N/A                     |
 | ARM            | Cortex-A76      | #1165522        | N/A                     |
 | ARM            | MMU-500         | #842869         | N/A                     |
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 6f483b2d8d..da72b02442 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -481,6 +481,16 @@ static const struct arm_cpu_capabilities arm_errata[] = {
         .capability = ARM64_WORKAROUND_AT_SPECULATE,
         MIDR_RANGE(MIDR_CORTEX_A76, 0, 2 << MIDR_VARIANT_SHIFT),
     },
+    {
+        .desc = "ARM erratum 1319537",
+        .capability = ARM64_WORKAROUND_AT_SPECULATE,
+        MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
+    },
+    {
+        .desc = "ARM erratum 1319367",
+        .capability = ARM64_WORKAROUND_AT_SPECULATE,
+        MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
+    },
     {},
 };
 
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Julien Grall]

The documentation is using a mix of ARM (old) and Arm (new). To stay
consistent, use only the new name.

Signed-off-by: Julien Grall <julien.grall@arm.com>

---

Cc: jgross@suse.com

    Changes in v2:
        - Patch added
---
 SUPPORT.md                                 | 50 +++++++++++++++---------------
 docs/INDEX                                 |  6 ++--
 docs/features/livepatch.pandoc             |  2 +-
 docs/features/sched_rtds.pandoc            |  2 +-
 docs/hypervisor-guide/code-coverage.rst    |  2 +-
 docs/man/xl.cfg.5.pod.in                   |  8 ++---
 docs/misc/arm/booting.txt                  | 10 +++---
 docs/misc/arm/device-tree/guest.txt        |  4 +--
 docs/misc/arm/early-printk.txt             |  2 +-
 docs/misc/arm/silicon-errata.txt           | 26 ++++++++--------
 docs/misc/console.txt                      |  2 +-
 docs/misc/efi.pandoc                       |  2 +-
 docs/misc/livepatch.pandoc                 |  8 ++---
 docs/misc/xen-command-line.pandoc          | 22 ++++++-------
 docs/process/xen-release-management.pandoc |  2 +-
 docs/specs/libxc-migration-stream.pandoc   |  6 ++--
 docs/specs/libxl-migration-stream.pandoc   |  2 +-
 17 files changed, 78 insertions(+), 78 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 375473a456..cf759319cc 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -31,11 +31,11 @@ supported in this document.
 
     Status: Supported
 
-### ARM v7 + Virtualization Extensions
+### Arm v7 + Virtualization Extensions
 
     Status: Supported
 
-### ARM v8
+### Arm v8
 
     Status: Supported
 
@@ -52,7 +52,7 @@ supported in this document.
 ### Host ACPI (via Domain 0)
 
     Status, x86 PV: Supported
-    Status, ARM: Experimental
+    Status, Arm: Experimental
 
 ### x86/Intel Platform QoS Technologies
 
@@ -62,10 +62,10 @@ supported in this document.
 
     Status, AMD IOMMU: Supported
     Status, Intel VT-d: Supported
-    Status, ARM SMMUv1: Supported
-    Status, ARM SMMUv2: Supported
+    Status, Arm SMMUv1: Supported
+    Status, Arm SMMUv2: Supported
 
-### ARM/GICv3 ITS
+### Arm/GICv3 ITS
 
 Extension to the GICv3 interrupt controller to support MSI.
 
@@ -102,9 +102,9 @@ Dom0 support requires an IOMMU (Intel VT-d / AMD IOMMU).
     Status, domU: Supported
     Status, dom0: Experimental
 
-### ARM
+### Arm
 
-ARM only has one guest type at the moment
+Arm only has one guest type at the moment
 
     Status: Supported
 
@@ -119,8 +119,8 @@ ARM only has one guest type at the moment
 Format which the toolstack accepts for direct-boot kernels
 
     Supported, x86: bzImage, ELF
-    Supported, ARM32: zImage
-    Supported, ARM64: Image
+    Supported, Arm32: zImage
+    Supported, Arm64: Image
 
 ### Dom0 init support for xl
 
@@ -158,10 +158,10 @@ Output of information in machine-parseable JSON format
 
     Status, NS16550: Supported
     Status, EHCI: Supported
-    Status, Cadence UART (ARM): Supported
-    Status, PL011 UART (ARM): Supported
-    Status, Exynos 4210 UART (ARM): Supported
-    Status, OMAP UART (ARM): Supported
+    Status, Cadence UART (Arm): Supported
+    Status, PL011 UART (Arm): Supported
+    Status, Exynos 4210 UART (Arm): Supported
+    Status, OMAP UART (Arm): Supported
     Status, SCI(F) UART: Supported
 
 ### Hypervisor 'debug keys'
@@ -242,7 +242,7 @@ Alternative p2m (altp2m) allows external monitoring of guest memory
 by maintaining multiple physical to machine (p2m) memory mappings.
 
     Status, x86 HVM: Tech Preview
-    Status, ARM: Tech Preview
+    Status, Arm: Tech Preview
 
 ## Resource Management
 
@@ -305,15 +305,15 @@ Enables NUMA aware scheduling in Xen
 NB that this refers to the ability of guests
 to have higher-level page table entries point directly to memory,
 improving TLB performance.
-On ARM, and on x86 in HAP mode,
+On Arm, and on x86 in HAP mode,
 the guest has whatever support is enabled by the hardware.
 
 This feature is independent
-of the ARM "page granularity" feature (see below).
+of the Arm "page granularity" feature (see below).
 
     Status, x86 HVM/PVH, HAP: Supported
     Status, x86 HVM/PVH, Shadow, 2MiB: Supported
-    Status, ARM: Supported
+    Status, Arm: Supported
 
 On x86 in shadow mode, only 2MiB (L2) superpages are available;
 furthermore, they do not have the performance characteristics
@@ -545,9 +545,9 @@ be issued an XSA, since that does weaken security.
 ### Live Patching
 
     Status, x86: Supported
-    Status, ARM: Experimental
+    Status, Arm: Experimental
 
-Compile time disabled for ARM by default.
+Compile time disabled for Arm by default.
 
 ### Virtual Machine Introspection
 
@@ -639,24 +639,24 @@ to be used in addition to QEMU.
 
 	Status: Experimental
 
-### ARM/Non-PCI device passthrough
+### Arm/Non-PCI device passthrough
 
     Status: Supported, not security supported
 
 Note that this still requires an IOMMU
 that covers the DMA of the device to be passed through.
 
-### ARM: 16K and 64K page granularity in guests
+### Arm: 16K and 64K page granularity in guests
 
     Status: Supported, with caveats
 
 No support for QEMU backends in a 16K or 64K domain.
 
-### ARM: Guest Device Tree support
+### Arm: Guest Device Tree support
 
     Status: Supported
 
-### ARM: Guest ACPI support
+### Arm: Guest ACPI support
 
     Status: Supported
 
@@ -762,7 +762,7 @@ including security support status, functional completeness, etc.
 Refer to the detailed definitions below.
 
 If support differs based on implementation
-(for instance, x86 / ARM, Linux / QEMU / FreeBSD),
+(for instance, x86 / Arm, Linux / QEMU / FreeBSD),
 one line for each set of implementations will be listed.
 
 ## Definition of Status labels
diff --git a/docs/INDEX b/docs/INDEX
index e673edd75c..8cd7c7cf65 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -1,5 +1,5 @@
 hypercall			Hypercall Interfaces
-hypercall/arm/index		ARM
+hypercall/arm/index		Arm
 hypercall/x86_32/index		x86_32
 hypercall/x86_64/index		x86_64
 
@@ -20,8 +20,8 @@ misc/vtd			VT-d HOWTO
 misc/xen-error-handling		Xen Error Handling
 misc/xenpaging			Xen Paging
 misc/xsm-flask			XSM/FLASK Configuration
-misc/arm/booting		How to boot Xen on ARM
-misc/arm/early-printk		Enabling early printk on ARM
+misc/arm/booting		How to boot Xen on Arm
+misc/arm/early-printk		Enabling early printk on Arm
 misc/arm/passthrough		Passthrough a device described in the Device Tree to a guest
 misc/arm/device-tree/booting	Device tree bindings to boot Xen
 misc/arm/device-tree/passthrough	Device tree binding to passthrough a device
diff --git a/docs/features/livepatch.pandoc b/docs/features/livepatch.pandoc
index 17f1cd0d05..8974b9d894 100644
--- a/docs/features/livepatch.pandoc
+++ b/docs/features/livepatch.pandoc
@@ -12,7 +12,7 @@
 
          Status: **Tech Preview/Experimental**
 
-   Architecture: ARM
+   Architecture: Arm
 
       Component: Hypervisor, toolstack
 ---------------- ----------------------------------------------------
diff --git a/docs/features/sched_rtds.pandoc b/docs/features/sched_rtds.pandoc
index 4ccf704b53..2a50cd1b4d 100644
--- a/docs/features/sched_rtds.pandoc
+++ b/docs/features/sched_rtds.pandoc
@@ -101,7 +101,7 @@ at a macroscopic level), the following should be done:
 
 # Known issues
 
-* OSSTest reports occasional failures on ARM.
+* OSSTest reports occasional failures on Arm.
 
 # References
 
diff --git a/docs/hypervisor-guide/code-coverage.rst b/docs/hypervisor-guide/code-coverage.rst
index 6c7552d691..1c70570037 100644
--- a/docs/hypervisor-guide/code-coverage.rst
+++ b/docs/hypervisor-guide/code-coverage.rst
@@ -8,7 +8,7 @@ so some extra steps are required to collect and process the data.
 
 .. warning::
 
-  ARM doesn't currently boot when the final binary exceeds 2MB in size,
+  Arm doesn't currently boot when the final binary exceeds 2MB in size,
   and the coverage build tends to exceed this limit.
 
 
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index e71b3b411d..dbb12e1558 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -1259,7 +1259,7 @@ Guests use hypervisor resources for each event channel they use.
 The default of 1023 should be sufficient for typical guests.  The
 maximum value depends on what the guest supports.  Guests supporting the
 FIFO-based event channel ABI support up to 131,071 event channels.
-Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
+Other guests are limited to 4095 (64-bit x86 and Arm) or 1023 (32-bit
 x86).
 
 =item B<vdispl=[ "VDISPL_SPEC_STRING", "VDISPL_SPEC_STRING", ...]>
@@ -1791,7 +1791,7 @@ the virtual firmware to the guest Operating System. ACPI is required
 by most modern guest Operating Systems. This option is enabled by
 default and usually you should omit it. However, it may be necessary to
 disable ACPI for compatibility with some guest Operating Systems.
-This option is true for x86 while it's false for ARM by default.
+This option is true for x86 while it's false for Arm by default.
 
 =item B<acpi_s3=BOOLEAN>
 
@@ -2707,7 +2707,7 @@ See B<qemu(1)> for more information.
 
 =head2 Architecture Specific options
 
-=head3 ARM
+=head3 Arm
 
 =over 4
 
@@ -2745,7 +2745,7 @@ VM config file:
 
 vuart = "sbsa_uart"
 
-Currently, only the "sbsa_uart" model is supported for ARM.
+Currently, only the "sbsa_uart" model is supported for Arm.
 
 =back
 
diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
index d3f6ce4755..69250c1f8d 100644
--- a/docs/misc/arm/booting.txt
+++ b/docs/misc/arm/booting.txt
@@ -1,13 +1,13 @@
 Booting Xen
 ===========
 
-Xen follows the zImage protocol defined for 32-bit ARM Linux[1] and the
-Image protocol defined for ARM64 Linux[2].
+Xen follows the zImage protocol defined for 32-bit Arm Linux[1] and the
+Image protocol defined for Arm64 Linux[2].
 
 In both cases the recommendation to boot in HYP/EL2 mode is a strict
 requirement for Xen.
 
-The exceptions to this on 32-bit ARM are as follows:
+The exceptions to this on 32-bit Arm are as follows:
 
  Xen does not require the machine type to be passed in r1. This
  register is ignored (so may be invalid or the actual machine type).
@@ -21,7 +21,7 @@ The exceptions to this on 32-bit ARM are as follows:
  zImage protocol should still be used and not the stricter "raw
  (non-zImage)" protocol described in arm/Booting.
 
-There are no exception on 64-bit ARM.
+There are no exception on 64-bit Arm.
 
 
 Firmware/bootloader requirements
@@ -31,7 +31,7 @@ Xen relies on some settings the firmware has to configure in EL3 before starting
 
 * Xen must be entered in NS EL2 mode
 
-* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
+* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit Arm) must be set to 1.
 
 
 [1] linux/Documentation/arm/Booting
diff --git a/docs/misc/arm/device-tree/guest.txt b/docs/misc/arm/device-tree/guest.txt
index 418f1e9f4e..5a76ba81e1 100644
--- a/docs/misc/arm/device-tree/guest.txt
+++ b/docs/misc/arm/device-tree/guest.txt
@@ -1,6 +1,6 @@
 * Xen hypervisor device tree bindings
 
-Xen ARM virtual platforms shall have a top-level "hypervisor" node with
+Xen Arm virtual platforms shall have a top-level "hypervisor" node with
 the following properties:
 
 - compatible:
@@ -17,7 +17,7 @@ the following properties:
   A GIC node is also required.
   This property is unnecessary when booting Dom0 using ACPI.
 
-To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
+To support UEFI on Xen Arm virtual platforms, Xen populates the FDT "uefi" node
 under /hypervisor with following parameters:
 
 ________________________________________________________________________________
diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index 89e081e51e..b53adeae49 100644
--- a/docs/misc/arm/early-printk.txt
+++ b/docs/misc/arm/early-printk.txt
@@ -41,7 +41,7 @@ the name of the machine:
   - brcm: printk with 8250 on Broadcom 7445D0 boards with A15 processors.
   - dra7: printk with 8250 on DRA7 platform
   - exynos5250: printk with the second UART
-  - fastmodel: printk on ARM Fastmodel software emulators
+  - fastmodel: printk on Arm Fastmodel software emulators
   - hikey960: printk with pl011 with Hikey 960
   - juno: printk with pl011 on Juno platform
   - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor)
diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 11e5a9dcec..4bb1a03b1e 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -3,7 +3,7 @@
 
 It is an unfortunate fact of life that hardware is often produced with
 so-called "errata", which can cause it to deviate from the architecture
-under specific circumstances.  For hardware produced by ARM, these
+under specific circumstances.  For hardware produced by Arm, these
 errata are broadly classified into the following categories:
 
   Category A: A critical error without a viable workaround.
@@ -29,7 +29,7 @@ For software workarounds that may adversely impact systems unaffected by
 the erratum in question, a Kconfig entry is added under "ARM errata
 workarounds via the alternatives framework". These are enabled by default
 and patched in at runtime when an affected CPU is detected. Note that
-runtime patching is only supported on ARM64. For less-intrusive workarounds,
+runtime patching is only supported on Arm64. For less-intrusive workarounds,
 a Kconfig option is not available and the code is structured (preferably
 with a comment) in such a way that the erratum will not be hit.
 
@@ -41,14 +41,14 @@ stable hypervisors.
 
 | Implementor    | Component       | Erratum ID      | Kconfig                 |
 +----------------+-----------------+-----------------+-------------------------+
-| ARM            | Cortex-A15      | #766422         | N/A                     |
-| ARM            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319    |
-| ARM            | Cortex-A53      | #824069         | ARM64_ERRATUM_824069    |
-| ARM            | Cortex-A53      | #819472         | ARM64_ERRATUM_819472    |
-| ARM            | Cortex-A57      | #852523         | N/A                     |
-| ARM            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |
-| ARM            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |
-| ARM            | Cortex-A57      | #1319537        | N/A                     |
-| ARM            | Cortex-A72      | #1319367        | N/A                     |
-| ARM            | Cortex-A76      | #1165522        | N/A                     |
-| ARM            | MMU-500         | #842869         | N/A                     |
+| Arm            | Cortex-A15      | #766422         | N/A                     |
+| Arm            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319    |
+| Arm            | Cortex-A53      | #824069         | ARM64_ERRATUM_824069    |
+| Arm            | Cortex-A53      | #819472         | ARM64_ERRATUM_819472    |
+| Arm            | Cortex-A57      | #852523         | N/A                     |
+| Arm            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |
+| Arm            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |
+| Arm            | Cortex-A57      | #1319537        | N/A                     |
+| Arm            | Cortex-A72      | #1319367        | N/A                     |
+| Arm            | Cortex-A76      | #1165522        | N/A                     |
+| Arm            | MMU-500         | #842869         | N/A                     |
diff --git a/docs/misc/console.txt b/docs/misc/console.txt
index 4e180f88ba..adbefd3955 100644
--- a/docs/misc/console.txt
+++ b/docs/misc/console.txt
@@ -23,7 +23,7 @@ The virtual UART console path in xenstore is defined as:
 
 /local/domain/$DOMID/vuart/0
 
-The vuart console provides access to a virtual SBSA UART on ARM systems.
+The vuart console provides access to a virtual SBSA UART on Arm systems.
 To enable vuart the following line has to be added to the guest configuration
 file:
 
diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
index 23c1a2732d..968f4980bd 100644
--- a/docs/misc/efi.pandoc
+++ b/docs/misc/efi.pandoc
@@ -103,7 +103,7 @@ Specifies a CPU microcode blob to load. (x86 only)
 Specifies a device tree file to load.  The platform firmware may provide a
 DTB in an EFI configuration table, so this field is optional in that
 case. A dtb specified in the configuration file will override a device tree
-provided in the EFI configuration table. (ARM only)
+provided in the EFI configuration table. (Arm only)
 
 ###`chain=<filename>`
 
diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index 6d9f72f49b..073541213b 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -313,7 +313,7 @@ The size of the structure is 64 bytes on 64-bit hypervisors. It will be
     the new function (which will replace the one at `old_addr`) in bytes.
    * If the value of `new_addr` is zero then `new_size` determines how many
     instruction bytes to NOP (up to opaque size modulo smallest platform
-    instruction - 1 byte x86 and 4 bytes on ARM).
+    instruction - 1 byte x86 and 4 bytes on Arm).
  * `version` is to be one.
  * `opaque` **MUST** be zero.
 
@@ -1091,7 +1091,7 @@ that in the hypervisor is advised.
 The tool for generating payloads currently does perform a compile-time
 check to ensure that the function to be replaced is large enough.
 
-#### Trampoline, ARM
+#### Trampoline, Arm
 
 The unconditional branch instruction (for the encoding see the
 DDI 0406C.c and DDI 0487A.j Architecture Reference Manual's).
@@ -1099,8 +1099,8 @@ with proper offset is used for an unconditional branch to the new code.
 This means that that `old_size` **MUST** be at least four bytes if patching
 in trampoline.
 
-The instruction offset is limited on ARM32 to +/- 32MB to displacement
-and on ARM64 to +/- 128MB displacement.
+The instruction offset is limited on Arm32 to +/- 32MB to displacement
+and on Arm64 to +/- 128MB displacement.
 
 The new code is placed in the 8M - 10M virtual address space while the
 Xen code is in 2M - 4M. That gives us enough space.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 832797e2e2..55dfb7420d 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -710,7 +710,7 @@ Controls for the dom0 IOMMU setup.
     available by fully disabling all IOMMUs.
 
     This option is hardwired to false for x86 PVH dom0's (where a non-identity
-    transform is required for dom0 to function), and is ignored for ARM.
+    transform is required for dom0 to function), and is ignored for Arm.
 
 *   The `strict` boolean is applicable to x86 PV dom0's only and defaults to
     false.  It controls whether dom0 can have IOMMU mappings for all domain
@@ -718,7 +718,7 @@ Controls for the dom0 IOMMU setup.
 
     This option is hardwired to true for x86 PVH dom0's (as RAM belonging to
     other domains in the system don't live in a compatible address space), and
-    is ignored for ARM.
+    is ignored for Arm.
 
 *   The `map-inclusive` boolean is applicable to x86 PV dom0's, and sets up
     identity IOMMU mappings for all non-RAM regions below 4GB except for
@@ -784,7 +784,7 @@ For example, with `dom0_max_vcpus=4-8`:
 >      8    |  8
 >     10    |  8
 
-### dom0_mem (ARM)
+### dom0_mem (Arm)
 > `= <size>`
 
 Set the amount of memory for the initial domain (dom0). It must be
@@ -849,7 +849,7 @@ affinities to prefer but be not limited to the specified node(s).
 
 Pin dom0 vcpus to their respective pcpus
 
-### dtuart (ARM)
+### dtuart (Arm)
 > `= path [:options]`
 
 > Default: `""`
@@ -1017,7 +1017,7 @@ version are 1 and 2.
 use of grant table v2 without transitive grants is an ABI breakage from the
 guests point of view.
 
-The usage of gnttab v2 is not security supported on ARM platforms.
+The usage of gnttab v2 is not security supported on Arm platforms.
 
 ### gnttab_max_frames
 > `= <integer>`
@@ -1225,7 +1225,7 @@ boolean (e.g. `iommu=no`) can override this and leave the IOMMUs disabled.
     hardware, and this option is ignored.  It is enabled by default on Intel
     systems.
 
-    This option is ignored on ARM, and the pagetables are always shared.
+    This option is ignored on Arm, and the pagetables are always shared.
 
 *   The `intremap` boolean controls the Interrupt Remapping sub-feature, and
     is active by default on compatible hardware.  On x86 systems, the first
@@ -1390,7 +1390,7 @@ based interrupts. Any higher IRQs will be available for use via PCI MSI.
 ### max_lpi_bits (arm)
 > `= <integer>`
 
-Specifies the number of ARM GICv3 LPI interrupts to allocate on the host,
+Specifies the number of Arm GICv3 LPI interrupts to allocate on the host,
 presented as the number of bits needed to encode it. This must be at least
 14 and not exceed 32, and each LPI requires one byte (configuration) and
 one pending bit to be allocated.
@@ -1417,7 +1417,7 @@ limit is ignored by Xen.
 > `= [<domU>][,[<ctldom>][,[<hwdom>][,<ptdom>]]]`
 
 > x86 default: `9,18,12,12`
-> ARM default: `9,18,10,10`
+> Arm default: `9,18,10,10`
 
 Change the maximum order permitted for allocation (or allocation-like)
 requests issued by the various kinds of domains (in this order:
@@ -1804,7 +1804,7 @@ accidentally leaking secrets by releasing pages without proper sanitization.
 
 Set the serial transmit buffer size.
 
-### serrors (ARM)
+### serrors (Arm)
 > `= diverse | forward | panic`
 
 > Default: `diverse`
@@ -2184,8 +2184,8 @@ production systems (see http://xenbits.xen.org/xsa/advisory-163.html)!
 
 > Default: `trap`
 
-WFI is the ARM instruction to "wait for interrupt". WFE is similar and
-means "wait for event". This option, which is ARM specific, changes the
+WFI is the Arm instruction to "wait for interrupt". WFE is similar and
+means "wait for event". This option, which is Arm specific, changes the
 way guest WFI and WFE are implemented in Xen. By default, Xen traps both
 instructions. In the case of WFI, Xen blocks the guest vcpu; in the case
 of WFE, Xen yield the guest vcpu. When setting vwfi to `native`, Xen
diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc
index d6abc90a02..96207c93f0 100644
--- a/docs/process/xen-release-management.pandoc
+++ b/docs/process/xen-release-management.pandoc
@@ -416,7 +416,7 @@ J: XEN-28
 
 === x86 ===
 
-=== ARM ===
+=== Arm ===
 
 == Completed ==
 
diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc
index 97dacb6e30..ddd7d1eb2f 100644
--- a/docs/specs/libxc-migration-stream.pandoc
+++ b/docs/specs/libxc-migration-stream.pandoc
@@ -30,7 +30,7 @@ image used in Xen 4.4 and earlier (the _legacy format_).
 
 A new format that addresses the above is required.
 
-ARM does not yet have have a domain save image format specified and
+Arm does not yet have have a domain save image format specified and
 the format described in this specification should be suitable.
 
 Not Yet Included
@@ -41,7 +41,7 @@ included in a future draft.
 
 * Page data compression.
 
-* ARM
+* Arm
 
 
 Overview
@@ -162,7 +162,7 @@ type        0x0000: Reserved.
 
             0x0003: x86 PVH.
 
-            0x0004: ARM.
+            0x0004: Arm.
 
             0x0005 - 0xFFFFFFFF: Reserved.
 
diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc
index 3766f37f4f..d407abd817 100644
--- a/docs/specs/libxl-migration-stream.pandoc
+++ b/docs/specs/libxl-migration-stream.pandoc
@@ -43,7 +43,7 @@ Not Yet Included
 The following features are not yet fully specified and will be
 included in a future draft.
 
-* ARM
+* Arm
 
 
 Overview
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 0/2] Errata implementation and doc update

[Jürgen Groß]

On 24.09.19 16:35, Julien Grall wrote:
> Hi all,
> 
> The two patches are not related but the second one dependends on the first
> one. So I decided to merge them together.
> 
> Cheers,
> 
> Julien Grall (2):
>    xen/arm: Implement workaround for Cortex A-57 and Cortex A72 AT
>      speculate
>    docs: Replace all instance of ARM by Arm

For the series:

Release-acked-by: Juergen Gross <jgross@suse.com>


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 0/2] Errata implementation and doc update

[Wei Liu]

On Tue, Sep 24, 2019 at 03:35:13PM +0100, Julien Grall wrote:
> Hi all,
> 
> The two patches are not related but the second one dependends on the first
> one. So I decided to merge them together.
> 
> Cheers,
> 
> Julien Grall (2):
>   xen/arm: Implement workaround for Cortex A-57 and Cortex A72 AT
>     speculate
>   docs: Replace all instance of ARM by Arm

Acked-by: Wei Liu <wl@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Volodymyr Babchuk]

Hi Julien,

Julien Grall writes:

> The documentation is using a mix of ARM (old) and Arm (new). To stay
> consistent, use only the new name.
>
Honestly, this rename confuses me. I think, this commit is the good
place to clarify a couple of questions.

1. How to write company name correctly? Looks like it is "Arm", despite
"arm" logo.

2. Correct name for architecture families is Arm, right? E.g. "Arm
processor" or "Arm system".

3. What about certain architecture? Arm site uses "Armv8-A", not
"Arm v8".

4. AFAIK, arm32 and arm64 are not existing officially, so should you
rename them?

5. What about "AArch64"/"AArch32"? Is this correct?

Slightly related question: Xen or XEN?

> Signed-off-by: Julien Grall <julien.grall@arm.com>
>
> ---
>
> Cc: jgross@suse.com
>
>     Changes in v2:
>         - Patch added
> ---
>  SUPPORT.md                                 | 50 +++++++++++++++---------------
>  docs/INDEX                                 |  6 ++--
>  docs/features/livepatch.pandoc             |  2 +-
>  docs/features/sched_rtds.pandoc            |  2 +-
>  docs/hypervisor-guide/code-coverage.rst    |  2 +-
>  docs/man/xl.cfg.5.pod.in                   |  8 ++---
>  docs/misc/arm/booting.txt                  | 10 +++---
>  docs/misc/arm/device-tree/guest.txt        |  4 +--
>  docs/misc/arm/early-printk.txt             |  2 +-
>  docs/misc/arm/silicon-errata.txt           | 26 ++++++++--------
>  docs/misc/console.txt                      |  2 +-
>  docs/misc/efi.pandoc                       |  2 +-
>  docs/misc/livepatch.pandoc                 |  8 ++---
>  docs/misc/xen-command-line.pandoc          | 22 ++++++-------
>  docs/process/xen-release-management.pandoc |  2 +-
>  docs/specs/libxc-migration-stream.pandoc   |  6 ++--
>  docs/specs/libxl-migration-stream.pandoc   |  2 +-
>  17 files changed, 78 insertions(+), 78 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 375473a456..cf759319cc 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -31,11 +31,11 @@ supported in this document.
>
>      Status: Supported
>
> -### ARM v7 + Virtualization Extensions
> +### Arm v7 + Virtualization Extensions
>
>      Status: Supported
>
> -### ARM v8
> +### Arm v8
>
>      Status: Supported
>
> @@ -52,7 +52,7 @@ supported in this document.
>  ### Host ACPI (via Domain 0)
>
>      Status, x86 PV: Supported
> -    Status, ARM: Experimental
> +    Status, Arm: Experimental
>
>  ### x86/Intel Platform QoS Technologies
>
> @@ -62,10 +62,10 @@ supported in this document.
>
>      Status, AMD IOMMU: Supported
>      Status, Intel VT-d: Supported
> -    Status, ARM SMMUv1: Supported
> -    Status, ARM SMMUv2: Supported
> +    Status, Arm SMMUv1: Supported
> +    Status, Arm SMMUv2: Supported
>
> -### ARM/GICv3 ITS
> +### Arm/GICv3 ITS
>
>  Extension to the GICv3 interrupt controller to support MSI.
>
> @@ -102,9 +102,9 @@ Dom0 support requires an IOMMU (Intel VT-d / AMD IOMMU).
>      Status, domU: Supported
>      Status, dom0: Experimental
>
> -### ARM
> +### Arm
>
> -ARM only has one guest type at the moment
> +Arm only has one guest type at the moment
>
>      Status: Supported
>
> @@ -119,8 +119,8 @@ ARM only has one guest type at the moment
>  Format which the toolstack accepts for direct-boot kernels
>
>      Supported, x86: bzImage, ELF
> -    Supported, ARM32: zImage
> -    Supported, ARM64: Image
> +    Supported, Arm32: zImage
> +    Supported, Arm64: Image
>
>  ### Dom0 init support for xl
>
> @@ -158,10 +158,10 @@ Output of information in machine-parseable JSON format
>
>      Status, NS16550: Supported
>      Status, EHCI: Supported
> -    Status, Cadence UART (ARM): Supported
> -    Status, PL011 UART (ARM): Supported
> -    Status, Exynos 4210 UART (ARM): Supported
> -    Status, OMAP UART (ARM): Supported
> +    Status, Cadence UART (Arm): Supported
> +    Status, PL011 UART (Arm): Supported
> +    Status, Exynos 4210 UART (Arm): Supported
> +    Status, OMAP UART (Arm): Supported
>      Status, SCI(F) UART: Supported
>
>  ### Hypervisor 'debug keys'
> @@ -242,7 +242,7 @@ Alternative p2m (altp2m) allows external monitoring of guest memory
>  by maintaining multiple physical to machine (p2m) memory mappings.
>
>      Status, x86 HVM: Tech Preview
> -    Status, ARM: Tech Preview
> +    Status, Arm: Tech Preview
>
>  ## Resource Management
>
> @@ -305,15 +305,15 @@ Enables NUMA aware scheduling in Xen
>  NB that this refers to the ability of guests
>  to have higher-level page table entries point directly to memory,
>  improving TLB performance.
> -On ARM, and on x86 in HAP mode,
> +On Arm, and on x86 in HAP mode,
>  the guest has whatever support is enabled by the hardware.
>
>  This feature is independent
> -of the ARM "page granularity" feature (see below).
> +of the Arm "page granularity" feature (see below).
>
>      Status, x86 HVM/PVH, HAP: Supported
>      Status, x86 HVM/PVH, Shadow, 2MiB: Supported
> -    Status, ARM: Supported
> +    Status, Arm: Supported
>
>  On x86 in shadow mode, only 2MiB (L2) superpages are available;
>  furthermore, they do not have the performance characteristics
> @@ -545,9 +545,9 @@ be issued an XSA, since that does weaken security.
>  ### Live Patching
>
>      Status, x86: Supported
> -    Status, ARM: Experimental
> +    Status, Arm: Experimental
>
> -Compile time disabled for ARM by default.
> +Compile time disabled for Arm by default.
>
>  ### Virtual Machine Introspection
>
> @@ -639,24 +639,24 @@ to be used in addition to QEMU.
>
>  	Status: Experimental
>
> -### ARM/Non-PCI device passthrough
> +### Arm/Non-PCI device passthrough
>
>      Status: Supported, not security supported
>
>  Note that this still requires an IOMMU
>  that covers the DMA of the device to be passed through.
>
> -### ARM: 16K and 64K page granularity in guests
> +### Arm: 16K and 64K page granularity in guests
>
>      Status: Supported, with caveats
>
>  No support for QEMU backends in a 16K or 64K domain.
>
> -### ARM: Guest Device Tree support
> +### Arm: Guest Device Tree support
>
>      Status: Supported
>
> -### ARM: Guest ACPI support
> +### Arm: Guest ACPI support
>
>      Status: Supported
>
> @@ -762,7 +762,7 @@ including security support status, functional completeness, etc.
>  Refer to the detailed definitions below.
>
>  If support differs based on implementation
> -(for instance, x86 / ARM, Linux / QEMU / FreeBSD),
> +(for instance, x86 / Arm, Linux / QEMU / FreeBSD),
>  one line for each set of implementations will be listed.
>
>  ## Definition of Status labels
> diff --git a/docs/INDEX b/docs/INDEX
> index e673edd75c..8cd7c7cf65 100644
> --- a/docs/INDEX
> +++ b/docs/INDEX
> @@ -1,5 +1,5 @@
>  hypercall			Hypercall Interfaces
> -hypercall/arm/index		ARM
> +hypercall/arm/index		Arm
>  hypercall/x86_32/index		x86_32
>  hypercall/x86_64/index		x86_64
>
> @@ -20,8 +20,8 @@ misc/vtd			VT-d HOWTO
>  misc/xen-error-handling		Xen Error Handling
>  misc/xenpaging			Xen Paging
>  misc/xsm-flask			XSM/FLASK Configuration
> -misc/arm/booting		How to boot Xen on ARM
> -misc/arm/early-printk		Enabling early printk on ARM
> +misc/arm/booting		How to boot Xen on Arm
> +misc/arm/early-printk		Enabling early printk on Arm
>  misc/arm/passthrough		Passthrough a device described in the Device Tree to a guest
>  misc/arm/device-tree/booting	Device tree bindings to boot Xen
>  misc/arm/device-tree/passthrough	Device tree binding to passthrough a device
> diff --git a/docs/features/livepatch.pandoc b/docs/features/livepatch.pandoc
> index 17f1cd0d05..8974b9d894 100644
> --- a/docs/features/livepatch.pandoc
> +++ b/docs/features/livepatch.pandoc
> @@ -12,7 +12,7 @@
>
>           Status: **Tech Preview/Experimental**
>
> -   Architecture: ARM
> +   Architecture: Arm
>
>        Component: Hypervisor, toolstack
>  ---------------- ----------------------------------------------------
> diff --git a/docs/features/sched_rtds.pandoc b/docs/features/sched_rtds.pandoc
> index 4ccf704b53..2a50cd1b4d 100644
> --- a/docs/features/sched_rtds.pandoc
> +++ b/docs/features/sched_rtds.pandoc
> @@ -101,7 +101,7 @@ at a macroscopic level), the following should be done:
>
>  # Known issues
>
> -* OSSTest reports occasional failures on ARM.
> +* OSSTest reports occasional failures on Arm.
>
>  # References
>
> diff --git a/docs/hypervisor-guide/code-coverage.rst b/docs/hypervisor-guide/code-coverage.rst
> index 6c7552d691..1c70570037 100644
> --- a/docs/hypervisor-guide/code-coverage.rst
> +++ b/docs/hypervisor-guide/code-coverage.rst
> @@ -8,7 +8,7 @@ so some extra steps are required to collect and process the data.
>
>  .. warning::
>
> -  ARM doesn't currently boot when the final binary exceeds 2MB in size,
> +  Arm doesn't currently boot when the final binary exceeds 2MB in size,
>    and the coverage build tends to exceed this limit.
>
>
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index e71b3b411d..dbb12e1558 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -1259,7 +1259,7 @@ Guests use hypervisor resources for each event channel they use.
>  The default of 1023 should be sufficient for typical guests.  The
>  maximum value depends on what the guest supports.  Guests supporting the
>  FIFO-based event channel ABI support up to 131,071 event channels.
> -Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
> +Other guests are limited to 4095 (64-bit x86 and Arm) or 1023 (32-bit
>  x86).
>
>  =item B<vdispl=[ "VDISPL_SPEC_STRING", "VDISPL_SPEC_STRING", ...]>
> @@ -1791,7 +1791,7 @@ the virtual firmware to the guest Operating System. ACPI is required
>  by most modern guest Operating Systems. This option is enabled by
>  default and usually you should omit it. However, it may be necessary to
>  disable ACPI for compatibility with some guest Operating Systems.
> -This option is true for x86 while it's false for ARM by default.
> +This option is true for x86 while it's false for Arm by default.
>
>  =item B<acpi_s3=BOOLEAN>
>
> @@ -2707,7 +2707,7 @@ See B<qemu(1)> for more information.
>
>  =head2 Architecture Specific options
>
> -=head3 ARM
> +=head3 Arm
>
>  =over 4
>
> @@ -2745,7 +2745,7 @@ VM config file:
>
>  vuart = "sbsa_uart"
>
> -Currently, only the "sbsa_uart" model is supported for ARM.
> +Currently, only the "sbsa_uart" model is supported for Arm.
>
>  =back
>
> diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
> index d3f6ce4755..69250c1f8d 100644
> --- a/docs/misc/arm/booting.txt
> +++ b/docs/misc/arm/booting.txt
> @@ -1,13 +1,13 @@
>  Booting Xen
>  ===========
>
> -Xen follows the zImage protocol defined for 32-bit ARM Linux[1] and the
> -Image protocol defined for ARM64 Linux[2].
> +Xen follows the zImage protocol defined for 32-bit Arm Linux[1] and the
> +Image protocol defined for Arm64 Linux[2].
>
>  In both cases the recommendation to boot in HYP/EL2 mode is a strict
>  requirement for Xen.
>
> -The exceptions to this on 32-bit ARM are as follows:
> +The exceptions to this on 32-bit Arm are as follows:
>
>   Xen does not require the machine type to be passed in r1. This
>   register is ignored (so may be invalid or the actual machine type).
> @@ -21,7 +21,7 @@ The exceptions to this on 32-bit ARM are as follows:
>   zImage protocol should still be used and not the stricter "raw
>   (non-zImage)" protocol described in arm/Booting.
>
> -There are no exception on 64-bit ARM.
> +There are no exception on 64-bit Arm.
>
>
>  Firmware/bootloader requirements
> @@ -31,7 +31,7 @@ Xen relies on some settings the firmware has to configure in EL3 before starting
>
>  * Xen must be entered in NS EL2 mode
>
> -* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
> +* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit Arm) must be set to 1.
>
>
>  [1] linux/Documentation/arm/Booting
> diff --git a/docs/misc/arm/device-tree/guest.txt b/docs/misc/arm/device-tree/guest.txt
> index 418f1e9f4e..5a76ba81e1 100644
> --- a/docs/misc/arm/device-tree/guest.txt
> +++ b/docs/misc/arm/device-tree/guest.txt
> @@ -1,6 +1,6 @@
>  * Xen hypervisor device tree bindings
>
> -Xen ARM virtual platforms shall have a top-level "hypervisor" node with
> +Xen Arm virtual platforms shall have a top-level "hypervisor" node with
>  the following properties:
>
>  - compatible:
> @@ -17,7 +17,7 @@ the following properties:
>    A GIC node is also required.
>    This property is unnecessary when booting Dom0 using ACPI.
>
> -To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
> +To support UEFI on Xen Arm virtual platforms, Xen populates the FDT "uefi" node
>  under /hypervisor with following parameters:
>
>  ________________________________________________________________________________
> diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
> index 89e081e51e..b53adeae49 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -41,7 +41,7 @@ the name of the machine:
>    - brcm: printk with 8250 on Broadcom 7445D0 boards with A15 processors.
>    - dra7: printk with 8250 on DRA7 platform
>    - exynos5250: printk with the second UART
> -  - fastmodel: printk on ARM Fastmodel software emulators
> +  - fastmodel: printk on Arm Fastmodel software emulators
>    - hikey960: printk with pl011 with Hikey 960
>    - juno: printk with pl011 on Juno platform
>    - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor)
> diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
> index 11e5a9dcec..4bb1a03b1e 100644
> --- a/docs/misc/arm/silicon-errata.txt
> +++ b/docs/misc/arm/silicon-errata.txt
> @@ -3,7 +3,7 @@
>
>  It is an unfortunate fact of life that hardware is often produced with
>  so-called "errata", which can cause it to deviate from the architecture
> -under specific circumstances.  For hardware produced by ARM, these
> +under specific circumstances.  For hardware produced by Arm, these
>  errata are broadly classified into the following categories:
>
>    Category A: A critical error without a viable workaround.
> @@ -29,7 +29,7 @@ For software workarounds that may adversely impact systems unaffected by
>  the erratum in question, a Kconfig entry is added under "ARM errata
>  workarounds via the alternatives framework". These are enabled by default
>  and patched in at runtime when an affected CPU is detected. Note that
> -runtime patching is only supported on ARM64. For less-intrusive workarounds,
> +runtime patching is only supported on Arm64. For less-intrusive workarounds,
>  a Kconfig option is not available and the code is structured (preferably
>  with a comment) in such a way that the erratum will not be hit.
>
> @@ -41,14 +41,14 @@ stable hypervisors.
>
>  | Implementor    | Component       | Erratum ID      | Kconfig                 |
>  +----------------+-----------------+-----------------+-------------------------+
> -| ARM            | Cortex-A15      | #766422         | N/A                     |
> -| ARM            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319    |
> -| ARM            | Cortex-A53      | #824069         | ARM64_ERRATUM_824069    |
> -| ARM            | Cortex-A53      | #819472         | ARM64_ERRATUM_819472    |
> -| ARM            | Cortex-A57      | #852523         | N/A                     |
> -| ARM            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |
> -| ARM            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |
> -| ARM            | Cortex-A57      | #1319537        | N/A                     |
> -| ARM            | Cortex-A72      | #1319367        | N/A                     |
> -| ARM            | Cortex-A76      | #1165522        | N/A                     |
> -| ARM            | MMU-500         | #842869         | N/A                     |
> +| Arm            | Cortex-A15      | #766422         | N/A                     |
> +| Arm            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319    |
> +| Arm            | Cortex-A53      | #824069         | ARM64_ERRATUM_824069    |
> +| Arm            | Cortex-A53      | #819472         | ARM64_ERRATUM_819472    |
> +| Arm            | Cortex-A57      | #852523         | N/A                     |
> +| Arm            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |
> +| Arm            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |
> +| Arm            | Cortex-A57      | #1319537        | N/A                     |
> +| Arm            | Cortex-A72      | #1319367        | N/A                     |
> +| Arm            | Cortex-A76      | #1165522        | N/A                     |
> +| Arm            | MMU-500         | #842869         | N/A                     |
> diff --git a/docs/misc/console.txt b/docs/misc/console.txt
> index 4e180f88ba..adbefd3955 100644
> --- a/docs/misc/console.txt
> +++ b/docs/misc/console.txt
> @@ -23,7 +23,7 @@ The virtual UART console path in xenstore is defined as:
>
>  /local/domain/$DOMID/vuart/0
>
> -The vuart console provides access to a virtual SBSA UART on ARM systems.
> +The vuart console provides access to a virtual SBSA UART on Arm systems.
>  To enable vuart the following line has to be added to the guest configuration
>  file:
>
> diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
> index 23c1a2732d..968f4980bd 100644
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -103,7 +103,7 @@ Specifies a CPU microcode blob to load. (x86 only)
>  Specifies a device tree file to load.  The platform firmware may provide a
>  DTB in an EFI configuration table, so this field is optional in that
>  case. A dtb specified in the configuration file will override a device tree
> -provided in the EFI configuration table. (ARM only)
> +provided in the EFI configuration table. (Arm only)
>
>  ###`chain=<filename>`
>
> diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
> index 6d9f72f49b..073541213b 100644
> --- a/docs/misc/livepatch.pandoc
> +++ b/docs/misc/livepatch.pandoc
> @@ -313,7 +313,7 @@ The size of the structure is 64 bytes on 64-bit hypervisors. It will be
>      the new function (which will replace the one at `old_addr`) in bytes.
>     * If the value of `new_addr` is zero then `new_size` determines how many
>      instruction bytes to NOP (up to opaque size modulo smallest platform
> -    instruction - 1 byte x86 and 4 bytes on ARM).
> +    instruction - 1 byte x86 and 4 bytes on Arm).
>   * `version` is to be one.
>   * `opaque` **MUST** be zero.
>
> @@ -1091,7 +1091,7 @@ that in the hypervisor is advised.
>  The tool for generating payloads currently does perform a compile-time
>  check to ensure that the function to be replaced is large enough.
>
> -#### Trampoline, ARM
> +#### Trampoline, Arm
>
>  The unconditional branch instruction (for the encoding see the
>  DDI 0406C.c and DDI 0487A.j Architecture Reference Manual's).
> @@ -1099,8 +1099,8 @@ with proper offset is used for an unconditional branch to the new code.
>  This means that that `old_size` **MUST** be at least four bytes if patching
>  in trampoline.
>
> -The instruction offset is limited on ARM32 to +/- 32MB to displacement
> -and on ARM64 to +/- 128MB displacement.
> +The instruction offset is limited on Arm32 to +/- 32MB to displacement
> +and on Arm64 to +/- 128MB displacement.
>
>  The new code is placed in the 8M - 10M virtual address space while the
>  Xen code is in 2M - 4M. That gives us enough space.
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 832797e2e2..55dfb7420d 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -710,7 +710,7 @@ Controls for the dom0 IOMMU setup.
>      available by fully disabling all IOMMUs.
>
>      This option is hardwired to false for x86 PVH dom0's (where a non-identity
> -    transform is required for dom0 to function), and is ignored for ARM.
> +    transform is required for dom0 to function), and is ignored for Arm.
>
>  *   The `strict` boolean is applicable to x86 PV dom0's only and defaults to
>      false.  It controls whether dom0 can have IOMMU mappings for all domain
> @@ -718,7 +718,7 @@ Controls for the dom0 IOMMU setup.
>
>      This option is hardwired to true for x86 PVH dom0's (as RAM belonging to
>      other domains in the system don't live in a compatible address space), and
> -    is ignored for ARM.
> +    is ignored for Arm.
>
>  *   The `map-inclusive` boolean is applicable to x86 PV dom0's, and sets up
>      identity IOMMU mappings for all non-RAM regions below 4GB except for
> @@ -784,7 +784,7 @@ For example, with `dom0_max_vcpus=4-8`:
>  >      8    |  8
>  >     10    |  8
>
> -### dom0_mem (ARM)
> +### dom0_mem (Arm)
>  > `= <size>`
>
>  Set the amount of memory for the initial domain (dom0). It must be
> @@ -849,7 +849,7 @@ affinities to prefer but be not limited to the specified node(s).
>
>  Pin dom0 vcpus to their respective pcpus
>
> -### dtuart (ARM)
> +### dtuart (Arm)
>  > `= path [:options]`
>
>  > Default: `""`
> @@ -1017,7 +1017,7 @@ version are 1 and 2.
>  use of grant table v2 without transitive grants is an ABI breakage from the
>  guests point of view.
>
> -The usage of gnttab v2 is not security supported on ARM platforms.
> +The usage of gnttab v2 is not security supported on Arm platforms.
>
>  ### gnttab_max_frames
>  > `= <integer>`
> @@ -1225,7 +1225,7 @@ boolean (e.g. `iommu=no`) can override this and leave the IOMMUs disabled.
>      hardware, and this option is ignored.  It is enabled by default on Intel
>      systems.
>
> -    This option is ignored on ARM, and the pagetables are always shared.
> +    This option is ignored on Arm, and the pagetables are always shared.
>
>  *   The `intremap` boolean controls the Interrupt Remapping sub-feature, and
>      is active by default on compatible hardware.  On x86 systems, the first
> @@ -1390,7 +1390,7 @@ based interrupts. Any higher IRQs will be available for use via PCI MSI.
>  ### max_lpi_bits (arm)
>  > `= <integer>`
>
> -Specifies the number of ARM GICv3 LPI interrupts to allocate on the host,
> +Specifies the number of Arm GICv3 LPI interrupts to allocate on the host,
>  presented as the number of bits needed to encode it. This must be at least
>  14 and not exceed 32, and each LPI requires one byte (configuration) and
>  one pending bit to be allocated.
> @@ -1417,7 +1417,7 @@ limit is ignored by Xen.
>  > `= [<domU>][,[<ctldom>][,[<hwdom>][,<ptdom>]]]`
>
>  > x86 default: `9,18,12,12`
> -> ARM default: `9,18,10,10`
> +> Arm default: `9,18,10,10`
>
>  Change the maximum order permitted for allocation (or allocation-like)
>  requests issued by the various kinds of domains (in this order:
> @@ -1804,7 +1804,7 @@ accidentally leaking secrets by releasing pages without proper sanitization.
>
>  Set the serial transmit buffer size.
>
> -### serrors (ARM)
> +### serrors (Arm)
>  > `= diverse | forward | panic`
>
>  > Default: `diverse`
> @@ -2184,8 +2184,8 @@ production systems (see http://xenbits.xen.org/xsa/advisory-163.html)!
>
>  > Default: `trap`
>
> -WFI is the ARM instruction to "wait for interrupt". WFE is similar and
> -means "wait for event". This option, which is ARM specific, changes the
> +WFI is the Arm instruction to "wait for interrupt". WFE is similar and
> +means "wait for event". This option, which is Arm specific, changes the
>  way guest WFI and WFE are implemented in Xen. By default, Xen traps both
>  instructions. In the case of WFI, Xen blocks the guest vcpu; in the case
>  of WFE, Xen yield the guest vcpu. When setting vwfi to `native`, Xen
> diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc
> index d6abc90a02..96207c93f0 100644
> --- a/docs/process/xen-release-management.pandoc
> +++ b/docs/process/xen-release-management.pandoc
> @@ -416,7 +416,7 @@ J: XEN-28
>
>  === x86 ===
>
> -=== ARM ===
> +=== Arm ===
>
>  == Completed ==
>
> diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc
> index 97dacb6e30..ddd7d1eb2f 100644
> --- a/docs/specs/libxc-migration-stream.pandoc
> +++ b/docs/specs/libxc-migration-stream.pandoc
> @@ -30,7 +30,7 @@ image used in Xen 4.4 and earlier (the _legacy format_).
>
>  A new format that addresses the above is required.
>
> -ARM does not yet have have a domain save image format specified and
> +Arm does not yet have have a domain save image format specified and
>  the format described in this specification should be suitable.
>
>  Not Yet Included
> @@ -41,7 +41,7 @@ included in a future draft.
>
>  * Page data compression.
>
> -* ARM
> +* Arm
>
>
>  Overview
> @@ -162,7 +162,7 @@ type        0x0000: Reserved.
>
>              0x0003: x86 PVH.
>
> -            0x0004: ARM.
> +            0x0004: Arm.
>
>              0x0005 - 0xFFFFFFFF: Reserved.
>
> diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc
> index 3766f37f4f..d407abd817 100644
> --- a/docs/specs/libxl-migration-stream.pandoc
> +++ b/docs/specs/libxl-migration-stream.pandoc
> @@ -43,7 +43,7 @@ Not Yet Included
>  The following features are not yet fully specified and will be
>  included in a future draft.
>
> -* ARM
> +* Arm
>
>
>  Overview


--
Volodymyr Babchuk at EPAM
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Julien Grall]

Hi,

On 9/24/19 3:56 PM, Volodymyr Babchuk wrote:
> Julien Grall writes:
> 
>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>> consistent, use only the new name.
>>
> Honestly, this rename confuses me. I think, this commit is the good
> place to clarify a couple of questions.

It did confuse a lot when the rename was made by Arm... What I want to 
avoid is mixing the both in the documentation as this makes things more 
difficult to follow.

There are probably more to tidy up, but then you have to start somewhere.

> 
> 1. How to write company name correctly? Looks like it is "Arm", despite
> "arm" logo.

When using in a sentence, the preferred version is "Arm" to avoid 
confusion with the word "arm".

For more information regarding the writing see: 
https://www.arm.com/company/policies/trademarks

For, the rest of the e-mail is more blur and this is based on my own 
opinion.

> 
> 2. Correct name for architecture families is Arm, right?

The Arm architecture

> E.g. "Arm
> processor" or "Arm system".

I am not sure which answer you are looking for here. For the former, you 
are speaking about a given processor (e.g. Cortex-A15) whilst the latter 
is a set of multiples processors + devices (i.e. SoC).

> 
> 3. What about certain architecture? Arm site uses "Armv8-A", not
> "Arm v8".

If you want to be pedantic, we should use Armv8-A. But it is widely 
accepted in the to use Armv8. The version "Arm v8" is not very common 
and should probably replaced.

> 
> 4. AFAIK, arm32 and arm64 are not existing officially, so should you
> rename them?

This is an abuse from Linux but commonly used. In Xen, we are abusing 
further and use Arm64 to refer to Armv8 system and Arm32 to refer to 
Armv7 system.

> 
> 5. What about "AArch64"/"AArch32"? Is this correct?

AArch64 and AArch32 is the correct naming per the spec.

> 
> Slightly related question: Xen or XEN?

I tend to use Xen. I don't know if there are any recommendation here.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Volodymyr Babchuk]

Julien Grall writes:

> Hi,
>
> On 9/24/19 3:56 PM, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>
>>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>>> consistent, use only the new name.
>>>
>> Honestly, this rename confuses me. I think, this commit is the good
>> place to clarify a couple of questions.
>
> It did confuse a lot when the rename was made by Arm... What I want to
> avoid is mixing the both in the documentation as this makes things
> more difficult to follow.
>
> There are probably more to tidy up, but then you have to start somewhere.

Thank you for explanation. Just in case: I have nothing against this
particular patch. I just wanted to understand how to use this names
correctly.

--
Volodymyr Babchuk at EPAM
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Julien Grall]

On 9/24/19 4:37 PM, Volodymyr Babchuk wrote:
> 
> Julien Grall writes:
> 
>> Hi,
>>
>> On 9/24/19 3:56 PM, Volodymyr Babchuk wrote:
>>> Julien Grall writes:
>>>
>>>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>>>> consistent, use only the new name.
>>>>
>>> Honestly, this rename confuses me. I think, this commit is the good
>>> place to clarify a couple of questions.
>>
>> It did confuse a lot when the rename was made by Arm... What I want to
>> avoid is mixing the both in the documentation as this makes things
>> more difficult to follow.
>>
>> There are probably more to tidy up, but then you have to start somewhere.
> 
> Thank you for explanation. Just in case: I have nothing against this
> particular patch. I just wanted to understand how to use this names
> correctly.

In short, it is pretty much the wild west in the documentation so far. :(

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 1/2] xen/arm: Implement workaround for Cortex A-57 and Cortex A72 AT speculate

[Stefano Stabellini]

On Tue, 24 Sep 2019, Julien Grall wrote:
> Both Cortex-A57 (erratum 1319537) and Cortex-A72 (erratum 1319367) can
> end with corrupt TLBs if they speculate an AT instruction while S1/S2
           ^ corrupted

> system registers in inconsistent state.
> 
> The workaround is the same as for Cortex A-76 implemented by commit
> a18be06aca "xen/arm: Implement workaround for Cortex-A76 erratum 1165522",
> so it is only necessary to plumb in the cpuerrata framework.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>     Changes in v2:
>         - Add missing |
> ---
>  docs/misc/arm/silicon-errata.txt |  2 ++
>  xen/arch/arm/cpuerrata.c         | 10 ++++++++++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
> index 6cd1366f15..11e5a9dcec 100644
> --- a/docs/misc/arm/silicon-errata.txt
> +++ b/docs/misc/arm/silicon-errata.txt
> @@ -48,5 +48,7 @@ stable hypervisors.
>  | ARM            | Cortex-A57      | #852523         | N/A                     |
>  | ARM            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |
>  | ARM            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |
> +| ARM            | Cortex-A57      | #1319537        | N/A                     |
> +| ARM            | Cortex-A72      | #1319367        | N/A                     |
>  | ARM            | Cortex-A76      | #1165522        | N/A                     |
>  | ARM            | MMU-500         | #842869         | N/A                     |
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 6f483b2d8d..da72b02442 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -481,6 +481,16 @@ static const struct arm_cpu_capabilities arm_errata[] = {
>          .capability = ARM64_WORKAROUND_AT_SPECULATE,
>          MIDR_RANGE(MIDR_CORTEX_A76, 0, 2 << MIDR_VARIANT_SHIFT),
>      },
> +    {
> +        .desc = "ARM erratum 1319537",
> +        .capability = ARM64_WORKAROUND_AT_SPECULATE,
> +        MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> +    },
> +    {
> +        .desc = "ARM erratum 1319367",
> +        .capability = ARM64_WORKAROUND_AT_SPECULATE,
> +        MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> +    },
>      {},
>  };
>  
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Stefano Stabellini]

On Tue, 24 Sep 2019, Julien Grall wrote:
> The documentation is using a mix of ARM (old) and Arm (new). To stay
> consistent, use only the new name.

Thank you for the patch, it must have been "not fun" to write this
patch.

However, let me suggest a radical maybe controversial idea. What about
keeping "ARM" instead of switching? There are several advantages: it is
easier to grep, no need to worry about case-sensitivity. It is what
people are used to, and what still use (in my experience at conference
and at work.) Would it make sense to ignore Arm's marketing and keep the
old "ARM" nomenclature?

If not, I'd suggest to also replace "arm" with "Arm" so that at least
with have consistent cases everywhere. But then the pathnames would
remain xen/arch/arm, leading to sentences such as:

 (non-zImage)" protocol described in arm/Booting.
  
 There are no exception on 64-bit Arm.

With "arm" and "ARM" the distinction was clear between pathnames and
text (at least to me.) With "arm" and "Arm", I know it is silly but it
kind of bothers me :-)

I am not going to insist on this one though.


> Signed-off-by: Julien Grall <julien.grall@arm.com>
> 
> ---
> 
> Cc: jgross@suse.com
> 
>     Changes in v2:
>         - Patch added
> ---
>  SUPPORT.md                                 | 50 +++++++++++++++---------------
>  docs/INDEX                                 |  6 ++--
>  docs/features/livepatch.pandoc             |  2 +-
>  docs/features/sched_rtds.pandoc            |  2 +-
>  docs/hypervisor-guide/code-coverage.rst    |  2 +-
>  docs/man/xl.cfg.5.pod.in                   |  8 ++---
>  docs/misc/arm/booting.txt                  | 10 +++---
>  docs/misc/arm/device-tree/guest.txt        |  4 +--
>  docs/misc/arm/early-printk.txt             |  2 +-
>  docs/misc/arm/silicon-errata.txt           | 26 ++++++++--------
>  docs/misc/console.txt                      |  2 +-
>  docs/misc/efi.pandoc                       |  2 +-
>  docs/misc/livepatch.pandoc                 |  8 ++---
>  docs/misc/xen-command-line.pandoc          | 22 ++++++-------
>  docs/process/xen-release-management.pandoc |  2 +-
>  docs/specs/libxc-migration-stream.pandoc   |  6 ++--
>  docs/specs/libxl-migration-stream.pandoc   |  2 +-
>  17 files changed, 78 insertions(+), 78 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 375473a456..cf759319cc 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -31,11 +31,11 @@ supported in this document.
>  
>      Status: Supported
>  
> -### ARM v7 + Virtualization Extensions
> +### Arm v7 + Virtualization Extensions
>  
>      Status: Supported
>  
> -### ARM v8
> +### Arm v8
>  
>      Status: Supported
>  
> @@ -52,7 +52,7 @@ supported in this document.
>  ### Host ACPI (via Domain 0)
>  
>      Status, x86 PV: Supported
> -    Status, ARM: Experimental
> +    Status, Arm: Experimental
>  
>  ### x86/Intel Platform QoS Technologies
>  
> @@ -62,10 +62,10 @@ supported in this document.
>  
>      Status, AMD IOMMU: Supported
>      Status, Intel VT-d: Supported
> -    Status, ARM SMMUv1: Supported
> -    Status, ARM SMMUv2: Supported
> +    Status, Arm SMMUv1: Supported
> +    Status, Arm SMMUv2: Supported
>  
> -### ARM/GICv3 ITS
> +### Arm/GICv3 ITS
>  
>  Extension to the GICv3 interrupt controller to support MSI.
>  
> @@ -102,9 +102,9 @@ Dom0 support requires an IOMMU (Intel VT-d / AMD IOMMU).
>      Status, domU: Supported
>      Status, dom0: Experimental
>  
> -### ARM
> +### Arm
>  
> -ARM only has one guest type at the moment
> +Arm only has one guest type at the moment
>  
>      Status: Supported
>  
> @@ -119,8 +119,8 @@ ARM only has one guest type at the moment
>  Format which the toolstack accepts for direct-boot kernels
>  
>      Supported, x86: bzImage, ELF
> -    Supported, ARM32: zImage
> -    Supported, ARM64: Image
> +    Supported, Arm32: zImage
> +    Supported, Arm64: Image
>  
>  ### Dom0 init support for xl
>  
> @@ -158,10 +158,10 @@ Output of information in machine-parseable JSON format
>  
>      Status, NS16550: Supported
>      Status, EHCI: Supported
> -    Status, Cadence UART (ARM): Supported
> -    Status, PL011 UART (ARM): Supported
> -    Status, Exynos 4210 UART (ARM): Supported
> -    Status, OMAP UART (ARM): Supported
> +    Status, Cadence UART (Arm): Supported
> +    Status, PL011 UART (Arm): Supported
> +    Status, Exynos 4210 UART (Arm): Supported
> +    Status, OMAP UART (Arm): Supported
>      Status, SCI(F) UART: Supported
>  
>  ### Hypervisor 'debug keys'
> @@ -242,7 +242,7 @@ Alternative p2m (altp2m) allows external monitoring of guest memory
>  by maintaining multiple physical to machine (p2m) memory mappings.
>  
>      Status, x86 HVM: Tech Preview
> -    Status, ARM: Tech Preview
> +    Status, Arm: Tech Preview
>  
>  ## Resource Management
>  
> @@ -305,15 +305,15 @@ Enables NUMA aware scheduling in Xen
>  NB that this refers to the ability of guests
>  to have higher-level page table entries point directly to memory,
>  improving TLB performance.
> -On ARM, and on x86 in HAP mode,
> +On Arm, and on x86 in HAP mode,
>  the guest has whatever support is enabled by the hardware.
>  
>  This feature is independent
> -of the ARM "page granularity" feature (see below).
> +of the Arm "page granularity" feature (see below).
>  
>      Status, x86 HVM/PVH, HAP: Supported
>      Status, x86 HVM/PVH, Shadow, 2MiB: Supported
> -    Status, ARM: Supported
> +    Status, Arm: Supported
>  
>  On x86 in shadow mode, only 2MiB (L2) superpages are available;
>  furthermore, they do not have the performance characteristics
> @@ -545,9 +545,9 @@ be issued an XSA, since that does weaken security.
>  ### Live Patching
>  
>      Status, x86: Supported
> -    Status, ARM: Experimental
> +    Status, Arm: Experimental
>  
> -Compile time disabled for ARM by default.
> +Compile time disabled for Arm by default.
>  
>  ### Virtual Machine Introspection
>  
> @@ -639,24 +639,24 @@ to be used in addition to QEMU.
>  
>  	Status: Experimental
>  
> -### ARM/Non-PCI device passthrough
> +### Arm/Non-PCI device passthrough
>  
>      Status: Supported, not security supported
>  
>  Note that this still requires an IOMMU
>  that covers the DMA of the device to be passed through.
>  
> -### ARM: 16K and 64K page granularity in guests
> +### Arm: 16K and 64K page granularity in guests
>  
>      Status: Supported, with caveats
>  
>  No support for QEMU backends in a 16K or 64K domain.
>  
> -### ARM: Guest Device Tree support
> +### Arm: Guest Device Tree support
>  
>      Status: Supported
>  
> -### ARM: Guest ACPI support
> +### Arm: Guest ACPI support
>  
>      Status: Supported
>  
> @@ -762,7 +762,7 @@ including security support status, functional completeness, etc.
>  Refer to the detailed definitions below.
>  
>  If support differs based on implementation
> -(for instance, x86 / ARM, Linux / QEMU / FreeBSD),
> +(for instance, x86 / Arm, Linux / QEMU / FreeBSD),
>  one line for each set of implementations will be listed.
>  
>  ## Definition of Status labels
> diff --git a/docs/INDEX b/docs/INDEX
> index e673edd75c..8cd7c7cf65 100644
> --- a/docs/INDEX
> +++ b/docs/INDEX
> @@ -1,5 +1,5 @@
>  hypercall			Hypercall Interfaces
> -hypercall/arm/index		ARM
> +hypercall/arm/index		Arm
>  hypercall/x86_32/index		x86_32
>  hypercall/x86_64/index		x86_64
>  
> @@ -20,8 +20,8 @@ misc/vtd			VT-d HOWTO
>  misc/xen-error-handling		Xen Error Handling
>  misc/xenpaging			Xen Paging
>  misc/xsm-flask			XSM/FLASK Configuration
> -misc/arm/booting		How to boot Xen on ARM
> -misc/arm/early-printk		Enabling early printk on ARM
> +misc/arm/booting		How to boot Xen on Arm
> +misc/arm/early-printk		Enabling early printk on Arm
>  misc/arm/passthrough		Passthrough a device described in the Device Tree to a guest
>  misc/arm/device-tree/booting	Device tree bindings to boot Xen
>  misc/arm/device-tree/passthrough	Device tree binding to passthrough a device
> diff --git a/docs/features/livepatch.pandoc b/docs/features/livepatch.pandoc
> index 17f1cd0d05..8974b9d894 100644
> --- a/docs/features/livepatch.pandoc
> +++ b/docs/features/livepatch.pandoc
> @@ -12,7 +12,7 @@
>  
>           Status: **Tech Preview/Experimental**
>  
> -   Architecture: ARM
> +   Architecture: Arm
>  
>        Component: Hypervisor, toolstack
>  ---------------- ----------------------------------------------------
> diff --git a/docs/features/sched_rtds.pandoc b/docs/features/sched_rtds.pandoc
> index 4ccf704b53..2a50cd1b4d 100644
> --- a/docs/features/sched_rtds.pandoc
> +++ b/docs/features/sched_rtds.pandoc
> @@ -101,7 +101,7 @@ at a macroscopic level), the following should be done:
>  
>  # Known issues
>  
> -* OSSTest reports occasional failures on ARM.
> +* OSSTest reports occasional failures on Arm.
>  
>  # References
>  
> diff --git a/docs/hypervisor-guide/code-coverage.rst b/docs/hypervisor-guide/code-coverage.rst
> index 6c7552d691..1c70570037 100644
> --- a/docs/hypervisor-guide/code-coverage.rst
> +++ b/docs/hypervisor-guide/code-coverage.rst
> @@ -8,7 +8,7 @@ so some extra steps are required to collect and process the data.
>  
>  .. warning::
>  
> -  ARM doesn't currently boot when the final binary exceeds 2MB in size,
> +  Arm doesn't currently boot when the final binary exceeds 2MB in size,
>    and the coverage build tends to exceed this limit.
>  
>  
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index e71b3b411d..dbb12e1558 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -1259,7 +1259,7 @@ Guests use hypervisor resources for each event channel they use.
>  The default of 1023 should be sufficient for typical guests.  The
>  maximum value depends on what the guest supports.  Guests supporting the
>  FIFO-based event channel ABI support up to 131,071 event channels.
> -Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
> +Other guests are limited to 4095 (64-bit x86 and Arm) or 1023 (32-bit
>  x86).
>  
>  =item B<vdispl=[ "VDISPL_SPEC_STRING", "VDISPL_SPEC_STRING", ...]>
> @@ -1791,7 +1791,7 @@ the virtual firmware to the guest Operating System. ACPI is required
>  by most modern guest Operating Systems. This option is enabled by
>  default and usually you should omit it. However, it may be necessary to
>  disable ACPI for compatibility with some guest Operating Systems.
> -This option is true for x86 while it's false for ARM by default.
> +This option is true for x86 while it's false for Arm by default.
>  
>  =item B<acpi_s3=BOOLEAN>
>  
> @@ -2707,7 +2707,7 @@ See B<qemu(1)> for more information.
>  
>  =head2 Architecture Specific options
>  
> -=head3 ARM
> +=head3 Arm
>  
>  =over 4
>  
> @@ -2745,7 +2745,7 @@ VM config file:
>  
>  vuart = "sbsa_uart"
>  
> -Currently, only the "sbsa_uart" model is supported for ARM.
> +Currently, only the "sbsa_uart" model is supported for Arm.
>  
>  =back
>  
> diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
> index d3f6ce4755..69250c1f8d 100644
> --- a/docs/misc/arm/booting.txt
> +++ b/docs/misc/arm/booting.txt
> @@ -1,13 +1,13 @@
>  Booting Xen
>  ===========
>  
> -Xen follows the zImage protocol defined for 32-bit ARM Linux[1] and the
> -Image protocol defined for ARM64 Linux[2].
> +Xen follows the zImage protocol defined for 32-bit Arm Linux[1] and the
> +Image protocol defined for Arm64 Linux[2].
>  
>  In both cases the recommendation to boot in HYP/EL2 mode is a strict
>  requirement for Xen.
>  
> -The exceptions to this on 32-bit ARM are as follows:
> +The exceptions to this on 32-bit Arm are as follows:
>  
>   Xen does not require the machine type to be passed in r1. This
>   register is ignored (so may be invalid or the actual machine type).
> @@ -21,7 +21,7 @@ The exceptions to this on 32-bit ARM are as follows:
>   zImage protocol should still be used and not the stricter "raw
>   (non-zImage)" protocol described in arm/Booting.
>  
> -There are no exception on 64-bit ARM.
> +There are no exception on 64-bit Arm.
>  
>  
>  Firmware/bootloader requirements
> @@ -31,7 +31,7 @@ Xen relies on some settings the firmware has to configure in EL3 before starting
>  
>  * Xen must be entered in NS EL2 mode
>  
> -* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
> +* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit Arm) must be set to 1.
>  
>  
>  [1] linux/Documentation/arm/Booting
> diff --git a/docs/misc/arm/device-tree/guest.txt b/docs/misc/arm/device-tree/guest.txt
> index 418f1e9f4e..5a76ba81e1 100644
> --- a/docs/misc/arm/device-tree/guest.txt
> +++ b/docs/misc/arm/device-tree/guest.txt
> @@ -1,6 +1,6 @@
>  * Xen hypervisor device tree bindings
>  
> -Xen ARM virtual platforms shall have a top-level "hypervisor" node with
> +Xen Arm virtual platforms shall have a top-level "hypervisor" node with
>  the following properties:
>  
>  - compatible:
> @@ -17,7 +17,7 @@ the following properties:
>    A GIC node is also required.
>    This property is unnecessary when booting Dom0 using ACPI.
>  
> -To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
> +To support UEFI on Xen Arm virtual platforms, Xen populates the FDT "uefi" node
>  under /hypervisor with following parameters:
>  
>  ________________________________________________________________________________
> diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
> index 89e081e51e..b53adeae49 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -41,7 +41,7 @@ the name of the machine:
>    - brcm: printk with 8250 on Broadcom 7445D0 boards with A15 processors.
>    - dra7: printk with 8250 on DRA7 platform
>    - exynos5250: printk with the second UART
> -  - fastmodel: printk on ARM Fastmodel software emulators
> +  - fastmodel: printk on Arm Fastmodel software emulators
>    - hikey960: printk with pl011 with Hikey 960
>    - juno: printk with pl011 on Juno platform
>    - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor)
> diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
> index 11e5a9dcec..4bb1a03b1e 100644
> --- a/docs/misc/arm/silicon-errata.txt
> +++ b/docs/misc/arm/silicon-errata.txt
> @@ -3,7 +3,7 @@
>  
>  It is an unfortunate fact of life that hardware is often produced with
>  so-called "errata", which can cause it to deviate from the architecture
> -under specific circumstances.  For hardware produced by ARM, these
> +under specific circumstances.  For hardware produced by Arm, these
>  errata are broadly classified into the following categories:
>  
>    Category A: A critical error without a viable workaround.
> @@ -29,7 +29,7 @@ For software workarounds that may adversely impact systems unaffected by
>  the erratum in question, a Kconfig entry is added under "ARM errata
>  workarounds via the alternatives framework". These are enabled by default
>  and patched in at runtime when an affected CPU is detected. Note that
> -runtime patching is only supported on ARM64. For less-intrusive workarounds,
> +runtime patching is only supported on Arm64. For less-intrusive workarounds,
>  a Kconfig option is not available and the code is structured (preferably
>  with a comment) in such a way that the erratum will not be hit.
>  
> @@ -41,14 +41,14 @@ stable hypervisors.
>  
>  | Implementor    | Component       | Erratum ID      | Kconfig                 |
>  +----------------+-----------------+-----------------+-------------------------+
> -| ARM            | Cortex-A15      | #766422         | N/A                     |
> -| ARM            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319    |
> -| ARM            | Cortex-A53      | #824069         | ARM64_ERRATUM_824069    |
> -| ARM            | Cortex-A53      | #819472         | ARM64_ERRATUM_819472    |
> -| ARM            | Cortex-A57      | #852523         | N/A                     |
> -| ARM            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |
> -| ARM            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |
> -| ARM            | Cortex-A57      | #1319537        | N/A                     |
> -| ARM            | Cortex-A72      | #1319367        | N/A                     |
> -| ARM            | Cortex-A76      | #1165522        | N/A                     |
> -| ARM            | MMU-500         | #842869         | N/A                     |
> +| Arm            | Cortex-A15      | #766422         | N/A                     |
> +| Arm            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319    |
> +| Arm            | Cortex-A53      | #824069         | ARM64_ERRATUM_824069    |
> +| Arm            | Cortex-A53      | #819472         | ARM64_ERRATUM_819472    |
> +| Arm            | Cortex-A57      | #852523         | N/A                     |
> +| Arm            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |
> +| Arm            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |
> +| Arm            | Cortex-A57      | #1319537        | N/A                     |
> +| Arm            | Cortex-A72      | #1319367        | N/A                     |
> +| Arm            | Cortex-A76      | #1165522        | N/A                     |
> +| Arm            | MMU-500         | #842869         | N/A                     |
> diff --git a/docs/misc/console.txt b/docs/misc/console.txt
> index 4e180f88ba..adbefd3955 100644
> --- a/docs/misc/console.txt
> +++ b/docs/misc/console.txt
> @@ -23,7 +23,7 @@ The virtual UART console path in xenstore is defined as:
>  
>  /local/domain/$DOMID/vuart/0
>  
> -The vuart console provides access to a virtual SBSA UART on ARM systems.
> +The vuart console provides access to a virtual SBSA UART on Arm systems.
>  To enable vuart the following line has to be added to the guest configuration
>  file:
>  
> diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
> index 23c1a2732d..968f4980bd 100644
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -103,7 +103,7 @@ Specifies a CPU microcode blob to load. (x86 only)
>  Specifies a device tree file to load.  The platform firmware may provide a
>  DTB in an EFI configuration table, so this field is optional in that
>  case. A dtb specified in the configuration file will override a device tree
> -provided in the EFI configuration table. (ARM only)
> +provided in the EFI configuration table. (Arm only)
>  
>  ###`chain=<filename>`
>  
> diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
> index 6d9f72f49b..073541213b 100644
> --- a/docs/misc/livepatch.pandoc
> +++ b/docs/misc/livepatch.pandoc
> @@ -313,7 +313,7 @@ The size of the structure is 64 bytes on 64-bit hypervisors. It will be
>      the new function (which will replace the one at `old_addr`) in bytes.
>     * If the value of `new_addr` is zero then `new_size` determines how many
>      instruction bytes to NOP (up to opaque size modulo smallest platform
> -    instruction - 1 byte x86 and 4 bytes on ARM).
> +    instruction - 1 byte x86 and 4 bytes on Arm).
>   * `version` is to be one.
>   * `opaque` **MUST** be zero.
>  
> @@ -1091,7 +1091,7 @@ that in the hypervisor is advised.
>  The tool for generating payloads currently does perform a compile-time
>  check to ensure that the function to be replaced is large enough.
>  
> -#### Trampoline, ARM
> +#### Trampoline, Arm
>  
>  The unconditional branch instruction (for the encoding see the
>  DDI 0406C.c and DDI 0487A.j Architecture Reference Manual's).
> @@ -1099,8 +1099,8 @@ with proper offset is used for an unconditional branch to the new code.
>  This means that that `old_size` **MUST** be at least four bytes if patching
>  in trampoline.
>  
> -The instruction offset is limited on ARM32 to +/- 32MB to displacement
> -and on ARM64 to +/- 128MB displacement.
> +The instruction offset is limited on Arm32 to +/- 32MB to displacement
> +and on Arm64 to +/- 128MB displacement.
>  
>  The new code is placed in the 8M - 10M virtual address space while the
>  Xen code is in 2M - 4M. That gives us enough space.
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 832797e2e2..55dfb7420d 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -710,7 +710,7 @@ Controls for the dom0 IOMMU setup.
>      available by fully disabling all IOMMUs.
>  
>      This option is hardwired to false for x86 PVH dom0's (where a non-identity
> -    transform is required for dom0 to function), and is ignored for ARM.
> +    transform is required for dom0 to function), and is ignored for Arm.
>  
>  *   The `strict` boolean is applicable to x86 PV dom0's only and defaults to
>      false.  It controls whether dom0 can have IOMMU mappings for all domain
> @@ -718,7 +718,7 @@ Controls for the dom0 IOMMU setup.
>  
>      This option is hardwired to true for x86 PVH dom0's (as RAM belonging to
>      other domains in the system don't live in a compatible address space), and
> -    is ignored for ARM.
> +    is ignored for Arm.
>  
>  *   The `map-inclusive` boolean is applicable to x86 PV dom0's, and sets up
>      identity IOMMU mappings for all non-RAM regions below 4GB except for
> @@ -784,7 +784,7 @@ For example, with `dom0_max_vcpus=4-8`:
>  >      8    |  8
>  >     10    |  8
>  
> -### dom0_mem (ARM)
> +### dom0_mem (Arm)
>  > `= <size>`
>  
>  Set the amount of memory for the initial domain (dom0). It must be
> @@ -849,7 +849,7 @@ affinities to prefer but be not limited to the specified node(s).
>  
>  Pin dom0 vcpus to their respective pcpus
>  
> -### dtuart (ARM)
> +### dtuart (Arm)
>  > `= path [:options]`
>  
>  > Default: `""`
> @@ -1017,7 +1017,7 @@ version are 1 and 2.
>  use of grant table v2 without transitive grants is an ABI breakage from the
>  guests point of view.
>  
> -The usage of gnttab v2 is not security supported on ARM platforms.
> +The usage of gnttab v2 is not security supported on Arm platforms.
>  
>  ### gnttab_max_frames
>  > `= <integer>`
> @@ -1225,7 +1225,7 @@ boolean (e.g. `iommu=no`) can override this and leave the IOMMUs disabled.
>      hardware, and this option is ignored.  It is enabled by default on Intel
>      systems.
>  
> -    This option is ignored on ARM, and the pagetables are always shared.
> +    This option is ignored on Arm, and the pagetables are always shared.
>  
>  *   The `intremap` boolean controls the Interrupt Remapping sub-feature, and
>      is active by default on compatible hardware.  On x86 systems, the first
> @@ -1390,7 +1390,7 @@ based interrupts. Any higher IRQs will be available for use via PCI MSI.
>  ### max_lpi_bits (arm)
>  > `= <integer>`
>  
> -Specifies the number of ARM GICv3 LPI interrupts to allocate on the host,
> +Specifies the number of Arm GICv3 LPI interrupts to allocate on the host,
>  presented as the number of bits needed to encode it. This must be at least
>  14 and not exceed 32, and each LPI requires one byte (configuration) and
>  one pending bit to be allocated.
> @@ -1417,7 +1417,7 @@ limit is ignored by Xen.
>  > `= [<domU>][,[<ctldom>][,[<hwdom>][,<ptdom>]]]`
>  
>  > x86 default: `9,18,12,12`
> -> ARM default: `9,18,10,10`
> +> Arm default: `9,18,10,10`
>  
>  Change the maximum order permitted for allocation (or allocation-like)
>  requests issued by the various kinds of domains (in this order:
> @@ -1804,7 +1804,7 @@ accidentally leaking secrets by releasing pages without proper sanitization.
>  
>  Set the serial transmit buffer size.
>  
> -### serrors (ARM)
> +### serrors (Arm)
>  > `= diverse | forward | panic`
>  
>  > Default: `diverse`
> @@ -2184,8 +2184,8 @@ production systems (see http://xenbits.xen.org/xsa/advisory-163.html)!
>  
>  > Default: `trap`
>  
> -WFI is the ARM instruction to "wait for interrupt". WFE is similar and
> -means "wait for event". This option, which is ARM specific, changes the
> +WFI is the Arm instruction to "wait for interrupt". WFE is similar and
> +means "wait for event". This option, which is Arm specific, changes the
>  way guest WFI and WFE are implemented in Xen. By default, Xen traps both
>  instructions. In the case of WFI, Xen blocks the guest vcpu; in the case
>  of WFE, Xen yield the guest vcpu. When setting vwfi to `native`, Xen
> diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc
> index d6abc90a02..96207c93f0 100644
> --- a/docs/process/xen-release-management.pandoc
> +++ b/docs/process/xen-release-management.pandoc
> @@ -416,7 +416,7 @@ J: XEN-28
>  
>  === x86 ===
>  
> -=== ARM ===
> +=== Arm ===
>  
>  == Completed ==
>  
> diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc
> index 97dacb6e30..ddd7d1eb2f 100644
> --- a/docs/specs/libxc-migration-stream.pandoc
> +++ b/docs/specs/libxc-migration-stream.pandoc
> @@ -30,7 +30,7 @@ image used in Xen 4.4 and earlier (the _legacy format_).
>  
>  A new format that addresses the above is required.
>  
> -ARM does not yet have have a domain save image format specified and
> +Arm does not yet have have a domain save image format specified and
>  the format described in this specification should be suitable.
>  
>  Not Yet Included
> @@ -41,7 +41,7 @@ included in a future draft.
>  
>  * Page data compression.
>  
> -* ARM
> +* Arm
>  
>  
>  Overview
> @@ -162,7 +162,7 @@ type        0x0000: Reserved.
>  
>              0x0003: x86 PVH.
>  
> -            0x0004: ARM.
> +            0x0004: Arm.
>  
>              0x0005 - 0xFFFFFFFF: Reserved.
>  
> diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc
> index 3766f37f4f..d407abd817 100644
> --- a/docs/specs/libxl-migration-stream.pandoc
> +++ b/docs/specs/libxl-migration-stream.pandoc
> @@ -43,7 +43,7 @@ Not Yet Included
>  The following features are not yet fully specified and will be
>  included in a future draft.
>  
> -* ARM
> +* Arm
>  
>  
>  Overview
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Julien Grall]

Hi Stefano,

On 10/2/19 2:05 AM, Stefano Stabellini wrote:
> On Tue, 24 Sep 2019, Julien Grall wrote:
>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>> consistent, use only the new name.
> 
> Thank you for the patch, it must have been "not fun" to write this
> patch.
> 
> However, let me suggest a radical maybe controversial idea. What about
> keeping "ARM" instead of switching? There are several advantages: it is
> easier to grep, no need to worry about case-sensitivity. 
> It is what
> people are used to, and what still use (in my experience at conference
> and at work.) Would it make sense to ignore Arm's marketing and keep the
> old "ARM" nomenclature?

Pretty much all the new documentation on Arm website are now using Arm 
(the spec is now called Arm Arm).

> 
> If not, I'd suggest to also replace "arm" with "Arm" so that at least
> with have consistent cases everywhere. But then the pathnames would
> remain xen/arch/arm, leading to sentences such as:
> 
>   (non-zImage)" protocol described in arm/Booting.
>    
>   There are no exception on 64-bit Arm.
> 
> With "arm" and "ARM" the distinction was clear between pathnames and
> text (at least to me.) With "arm" and "Arm", I know it is silly but it
> kind of bothers me :-)

How do you deal with Xilinx then? ;)

> 
> I am not going to insist on this one though.

This is quite similar to a company renaming itself (or got acquired and 
the name completely disappear) but in a less radical way. Would you 
still keep the old name company in your documentation and/or mixing the 
both?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Volodymyr Babchuk]

Hi Julien,

Julien Grall writes:

> Hi Stefano,
>
> On 10/2/19 2:05 AM, Stefano Stabellini wrote:
>> On Tue, 24 Sep 2019, Julien Grall wrote:
>>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>>> consistent, use only the new name.
>>
>> Thank you for the patch, it must have been "not fun" to write this
>> patch.
>>
>> However, let me suggest a radical maybe controversial idea. What about
>> keeping "ARM" instead of switching? There are several advantages: it is
>> easier to grep, no need to worry about case-sensitivity. It is what
>> people are used to, and what still use (in my experience at conference
>> and at work.) Would it make sense to ignore Arm's marketing and keep the
>> old "ARM" nomenclature?
>
> Pretty much all the new documentation on Arm website are now using Arm
> (the spec is now called Arm Arm).
This confuses me, because I believed that second "Arm" stands for
Architecture Reference Manual.

>>
>> If not, I'd suggest to also replace "arm" with "Arm" so that at least
>> with have consistent cases everywhere. But then the pathnames would
>> remain xen/arch/arm, leading to sentences such as:
>>
>>   (non-zImage)" protocol described in arm/Booting.
>>      There are no exception on 64-bit Arm.
>>
>> With "arm" and "ARM" the distinction was clear between pathnames and
>> text (at least to me.) With "arm" and "Arm", I know it is silly but it
>> kind of bothers me :-)
>
> How do you deal with Xilinx then? ;)
>
>>
>> I am not going to insist on this one though.
>
> This is quite similar to a company renaming itself (or got acquired
> and the name completely disappear) but in a less radical way. Would
> you still keep the old name company in your documentation and/or
> mixing the both?
BTW, this if what happened with Freescale/NXP. Linux and U-Boot still
use "freescale" even for i.MX8 chips.

-- 
Volodymyr Babchuk at EPAM
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Julien Grall]

Hi,

On 03/10/2019 16:55, Volodymyr Babchuk wrote:
> Julien Grall writes:
> 
>> Hi Stefano,
>>
>> On 10/2/19 2:05 AM, Stefano Stabellini wrote:
>>> On Tue, 24 Sep 2019, Julien Grall wrote:
>>>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>>>> consistent, use only the new name.
>>>
>>> Thank you for the patch, it must have been "not fun" to write this
>>> patch.
>>>
>>> However, let me suggest a radical maybe controversial idea. What about
>>> keeping "ARM" instead of switching? There are several advantages: it is
>>> easier to grep, no need to worry about case-sensitivity. It is what
>>> people are used to, and what still use (in my experience at conference
>>> and at work.) Would it make sense to ignore Arm's marketing and keep the
>>> old "ARM" nomenclature?
>>
>> Pretty much all the new documentation on Arm website are now using Arm
>> (the spec is now called Arm Arm).
> This confuses me, because I believed that second "Arm" stands for
> Architecture Reference Manual.
Sorry it is Arm ARM. But they tend to use the longer name Arm Architecture 
Reference Manual.

> 
>>>
>>> If not, I'd suggest to also replace "arm" with "Arm" so that at least
>>> with have consistent cases everywhere. But then the pathnames would
>>> remain xen/arch/arm, leading to sentences such as:
>>>
>>>    (non-zImage)" protocol described in arm/Booting.
>>>       There are no exception on 64-bit Arm.
>>>
>>> With "arm" and "ARM" the distinction was clear between pathnames and
>>> text (at least to me.) With "arm" and "Arm", I know it is silly but it
>>> kind of bothers me :-)
>>
>> How do you deal with Xilinx then? ;)
>>
>>>
>>> I am not going to insist on this one though.
>>
>> This is quite similar to a company renaming itself (or got acquired
>> and the name completely disappear) but in a less radical way. Would
>> you still keep the old name company in your documentation and/or
>> mixing the both?
> BTW, this if what happened with Freescale/NXP. Linux and U-Boot still
> use "freescale" even for i.MX8 chips.

Maybe because nobody bothered to do it? I would like some consistency in the 
documentation and hence using the new name makes sense. But I am not bothered 
enough to argue whether we should stay in the past.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Julien Grall]

Hi,

Gentle, ping. I don't think there are any conclusion here.

Should we stick to ARM or move to Arm?

Cheers,

On 10/3/19 5:02 PM, Julien Grall wrote:
> Hi,
> 
> On 03/10/2019 16:55, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>
>>> Hi Stefano,
>>>
>>> On 10/2/19 2:05 AM, Stefano Stabellini wrote:
>>>> On Tue, 24 Sep 2019, Julien Grall wrote:
>>>>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>>>>> consistent, use only the new name.
>>>>
>>>> Thank you for the patch, it must have been "not fun" to write this
>>>> patch.
>>>>
>>>> However, let me suggest a radical maybe controversial idea. What about
>>>> keeping "ARM" instead of switching? There are several advantages: it is
>>>> easier to grep, no need to worry about case-sensitivity. It is what
>>>> people are used to, and what still use (in my experience at conference
>>>> and at work.) Would it make sense to ignore Arm's marketing and keep 
>>>> the
>>>> old "ARM" nomenclature?
>>>
>>> Pretty much all the new documentation on Arm website are now using Arm
>>> (the spec is now called Arm Arm).
>> This confuses me, because I believed that second "Arm" stands for
>> Architecture Reference Manual.
> Sorry it is Arm ARM. But they tend to use the longer name Arm 
> Architecture Reference Manual.
> 
>>
>>>>
>>>> If not, I'd suggest to also replace "arm" with "Arm" so that at least
>>>> with have consistent cases everywhere. But then the pathnames would
>>>> remain xen/arch/arm, leading to sentences such as:
>>>>
>>>>    (non-zImage)" protocol described in arm/Booting.
>>>>       There are no exception on 64-bit Arm.
>>>>
>>>> With "arm" and "ARM" the distinction was clear between pathnames and
>>>> text (at least to me.) With "arm" and "Arm", I know it is silly but it
>>>> kind of bothers me :-)
>>>
>>> How do you deal with Xilinx then? ;)
>>>
>>>>
>>>> I am not going to insist on this one though.
>>>
>>> This is quite similar to a company renaming itself (or got acquired
>>> and the name completely disappear) but in a less radical way. Would
>>> you still keep the old name company in your documentation and/or
>>> mixing the both?
>> BTW, this if what happened with Freescale/NXP. Linux and U-Boot still
>> use "freescale" even for i.MX8 chips.
> 
> Maybe because nobody bothered to do it? I would like some consistency in 
> the documentation and hence using the new name makes sense. But I am not 
> bothered enough to argue whether we should stay in the past.
> 
> Cheers,
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]

I am OK switching to "Arm", however I would do it post-4.13: this is not
the kind of thing we should worry about it now I think.

On Tue, 15 Oct 2019, Julien Grall wrote:
> Hi,
> 
> Gentle, ping. I don't think there are any conclusion here.
> 
> Should we stick to ARM or move to Arm?
> 
> Cheers,
> 
> On 10/3/19 5:02 PM, Julien Grall wrote:
> > Hi,
> > 
> > On 03/10/2019 16:55, Volodymyr Babchuk wrote:
> > > Julien Grall writes:
> > > 
> > > > Hi Stefano,
> > > > 
> > > > On 10/2/19 2:05 AM, Stefano Stabellini wrote:
> > > > > On Tue, 24 Sep 2019, Julien Grall wrote:
> > > > > > The documentation is using a mix of ARM (old) and Arm (new). To stay
> > > > > > consistent, use only the new name.
> > > > > 
> > > > > Thank you for the patch, it must have been "not fun" to write this
> > > > > patch.
> > > > > 
> > > > > However, let me suggest a radical maybe controversial idea. What about
> > > > > keeping "ARM" instead of switching? There are several advantages: it
> > > > > is
> > > > > easier to grep, no need to worry about case-sensitivity. It is what
> > > > > people are used to, and what still use (in my experience at conference
> > > > > and at work.) Would it make sense to ignore Arm's marketing and keep
> > > > > the
> > > > > old "ARM" nomenclature?
> > > > 
> > > > Pretty much all the new documentation on Arm website are now using Arm
> > > > (the spec is now called Arm Arm).
> > > This confuses me, because I believed that second "Arm" stands for
> > > Architecture Reference Manual.
> > Sorry it is Arm ARM. But they tend to use the longer name Arm Architecture
> > Reference Manual.
> > 
> > > 
> > > > > 
> > > > > If not, I'd suggest to also replace "arm" with "Arm" so that at least
> > > > > with have consistent cases everywhere. But then the pathnames would
> > > > > remain xen/arch/arm, leading to sentences such as:
> > > > > 
> > > > >    (non-zImage)" protocol described in arm/Booting.
> > > > >       There are no exception on 64-bit Arm.
> > > > > 
> > > > > With "arm" and "ARM" the distinction was clear between pathnames and
> > > > > text (at least to me.) With "arm" and "Arm", I know it is silly but it
> > > > > kind of bothers me :-)
> > > > 
> > > > How do you deal with Xilinx then? ;)
> > > > 
> > > > > 
> > > > > I am not going to insist on this one though.
> > > > 
> > > > This is quite similar to a company renaming itself (or got acquired
> > > > and the name completely disappear) but in a less radical way. Would
> > > > you still keep the old name company in your documentation and/or
> > > > mixing the both?
> > > BTW, this if what happened with Freescale/NXP. Linux and U-Boot still
> > > use "freescale" even for i.MX8 chips.
> > 
> > Maybe because nobody bothered to do it? I would like some consistency in the
> > documentation and hence using the new name makes sense. But I am not
> > bothered enough to argue whether we should stay in the past.
> > 
> > Cheers,
> > 
> 
> -- 
> Julien Grall
> 

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Julien Grall]

On 10/15/19 5:47 PM, Stefano Stabellini wrote:
> I am OK switching to "Arm", however I would do it post-4.13: this is not
> the kind of thing we should worry about it now I think.

ok, I will move to my next queue.

Cheers,

> 
> On Tue, 15 Oct 2019, Julien Grall wrote:
>> Hi,
>>
>> Gentle, ping. I don't think there are any conclusion here.
>>
>> Should we stick to ARM or move to Arm?
>>
>> Cheers,
>>
>> On 10/3/19 5:02 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 03/10/2019 16:55, Volodymyr Babchuk wrote:
>>>> Julien Grall writes:
>>>>
>>>>> Hi Stefano,
>>>>>
>>>>> On 10/2/19 2:05 AM, Stefano Stabellini wrote:
>>>>>> On Tue, 24 Sep 2019, Julien Grall wrote:
>>>>>>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>>>>>>> consistent, use only the new name.
>>>>>>
>>>>>> Thank you for the patch, it must have been "not fun" to write this
>>>>>> patch.
>>>>>>
>>>>>> However, let me suggest a radical maybe controversial idea. What about
>>>>>> keeping "ARM" instead of switching? There are several advantages: it
>>>>>> is
>>>>>> easier to grep, no need to worry about case-sensitivity. It is what
>>>>>> people are used to, and what still use (in my experience at conference
>>>>>> and at work.) Would it make sense to ignore Arm's marketing and keep
>>>>>> the
>>>>>> old "ARM" nomenclature?
>>>>>
>>>>> Pretty much all the new documentation on Arm website are now using Arm
>>>>> (the spec is now called Arm Arm).
>>>> This confuses me, because I believed that second "Arm" stands for
>>>> Architecture Reference Manual.
>>> Sorry it is Arm ARM. But they tend to use the longer name Arm Architecture
>>> Reference Manual.
>>>
>>>>
>>>>>>
>>>>>> If not, I'd suggest to also replace "arm" with "Arm" so that at least
>>>>>> with have consistent cases everywhere. But then the pathnames would
>>>>>> remain xen/arch/arm, leading to sentences such as:
>>>>>>
>>>>>>     (non-zImage)" protocol described in arm/Booting.
>>>>>>        There are no exception on 64-bit Arm.
>>>>>>
>>>>>> With "arm" and "ARM" the distinction was clear between pathnames and
>>>>>> text (at least to me.) With "arm" and "Arm", I know it is silly but it
>>>>>> kind of bothers me :-)
>>>>>
>>>>> How do you deal with Xilinx then? ;)
>>>>>
>>>>>>
>>>>>> I am not going to insist on this one though.
>>>>>
>>>>> This is quite similar to a company renaming itself (or got acquired
>>>>> and the name completely disappear) but in a less radical way. Would
>>>>> you still keep the old name company in your documentation and/or
>>>>> mixing the both?
>>>> BTW, this if what happened with Freescale/NXP. Linux and U-Boot still
>>>> use "freescale" even for i.MX8 chips.
>>>
>>> Maybe because nobody bothered to do it? I would like some consistency in the
>>> documentation and hence using the new name makes sense. But I am not
>>> bothered enough to argue whether we should stay in the past.
>>>
>>> Cheers,
>>>
>>
>> -- 
>> Julien Grall

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel