On Tue, 7 Sept 2021 at 13:23, <marcandre.lureau@redhat.com> wrote:
>
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> I was looking for such documentation, but couldn't find it.
Yes; this is definitely something we should document, and in
the build-platforms doc is as good a place as any.
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> docs/about/build-platforms.rst | 28 ++++++++++++++++++++++++++++
> meson.build | 2 +-
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
> index 692323609e..bfe90e574e 100644
> --- a/docs/about/build-platforms.rst
> +++ b/docs/about/build-platforms.rst
> @@ -29,6 +29,34 @@ The `Repology`_ site is a useful resource to identify
> currently shipped versions of software in various operating systems,
> though it does not cover all distros listed below.
>
> +Supported host CPUs
> +-------------------
> +
> +Those host CPUs have a native TCG backend and are regularly tested:
This is a list of host architectures, not CPUs.
Isn't it CPU architecture we are talking about? (CPU for short in the title)
> + .. list-table::
> + :header-rows: 1
> +
> + * - CPU Family
I'll change this to CPU Architecture
> + - Accelerators
> + * - ARM
The correct capitalization these days is "Arm", by the way :-)
ok
You also should split 64-bit and 32-bit Arm; we support
KVM on 64-bit but not 32-bit.
When such a difference exists, I just added "(64 bit only)", see below for x86.
> + - kvm, xen
> + * - MIPS
> + - kvm
> + * - PPC
> + - kvm
> + * - RISC-V
> + -
> + * - s390x
> + - kvm
> + * - SPARC
> + -
> + * - x86
> + - kvm, xen, hax, hvf (64 bit only), nvmm, whpx (64 bit only)
> +
> +Other architectures are not actively maintained. They use the slow and
> +experimental TCG interpreter. They may be removed in future releases.
This seems to be conflating TCG and the TCG interpreter.
We should just list which architectures we support (proper)
TCG for, and say that everything else is unsupported
(not mentioning the TCG interpreter at all; using it is
pretty much always a mistake IMHO).
ok
The table also seems to me to be a bit confusing, because
the introductory text suggests it's a list of the TCG
support for each architecture, but the table itself lists
only the non-TCG accelerators. I think we should just list
all the accelerators supported for each host architecture.
All the architectures we support (in the list) have proper TCG, right?
Perhaps we should also (eventually) have somewhere some text
describing each accelerator in more detail, though probably
not in this file. A docs/system/accels.rst that described all
the accelerators with a paragraph or so for each, maybe ?
That could be really useful, but I am not up to the task at this point.
thanks