Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm
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
Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm
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 > ___ 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
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
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
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
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
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 > > --- > > Cc: jgr...@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,
Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm
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 2/2] docs: Replace all instance of ARM by Arm
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
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
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 > > --- > > Cc: jgr...@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)
[Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm
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 --- Cc: jgr...@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
