From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E311BC433EF for ; Mon, 13 Sep 2021 11:33:45 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 469C76044F for ; Mon, 13 Sep 2021 11:33:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 469C76044F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:47050 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mPkDY-0003T2-2J for qemu-devel@archiver.kernel.org; Mon, 13 Sep 2021 07:33:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mPkCW-0002WQ-TH for qemu-devel@nongnu.org; Mon, 13 Sep 2021 07:32:40 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:30102) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mPkCS-0004BQ-RF for qemu-devel@nongnu.org; Mon, 13 Sep 2021 07:32:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631532753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3gK1VqUjpK+KnEpOu7cDZlXNWVvCJEgCwkcGLhGkezU=; b=dpfs+ZKKUqFYm5LxS27gk9pzGGYlt1CClZVB/GihFGTUE4RPJXiPQOlNtnOgzBBRA/WR5y 5VaJphioAUsMyJGzYijfcXh4jBnC66WbnDr86Uvp9O/8XC2C2OxCqivHggdyIidHqUQk7b 68uYICCA96drg0B4EBThcCPbmQiBmdU= Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-481-rvacRNrVNWCSCLMccj4i_Q-1; Mon, 13 Sep 2021 07:32:30 -0400 X-MC-Unique: rvacRNrVNWCSCLMccj4i_Q-1 Received: by mail-pl1-f198.google.com with SMTP id z10-20020a170903018a00b00134def0a883so3122232plg.0 for ; Mon, 13 Sep 2021 04:32:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3gK1VqUjpK+KnEpOu7cDZlXNWVvCJEgCwkcGLhGkezU=; b=O5P16EQs0V8dwpNALwr/1dbj9h4zsKhuz1YkSVKruERipiFbV86vlPE2x6KuEsbLgi s+Feldt3mR12b92Zi2uq//fH676xbrCKCamMgQOTgJu+CgJGeCbsPbbbRi6nFtH2MWgr yAH5KHrAifyzWwnoMbgu7YP6g3M56Phe6+E4Z9O6+b7faQqYrvGrRFNRPcaXfNFWIgEp jh6ThvVCAn+zN/q4oVM6UmssyunR+kk2dLqFJgGm03CY8enoYU7yMN2sRIegvKy3NxSK Uka8Ujb0VWCEIJAV5Nd+pOCeCOZT/WQ9iv6IIWF9N3dbGZr0dbF1BOyMNchgkgzubuJy aUCw== X-Gm-Message-State: AOAM531Y1V77LruXWvfd//n7dCi/iXlGVpYiAVT5yDMqfk+aCIOf1zuM vSkS1MNuOXBayXTWw8ldm0srwvkNiEmUAoBlYzZJdC+8sTMVwvXIOn8pAAp2+uZVn6v7idcyuh2 myiXzcDO+2IteTjmaVFJFa75cgpjt/eA= X-Received: by 2002:aa7:9ae9:0:b0:3f5:e1a7:db23 with SMTP id y9-20020aa79ae9000000b003f5e1a7db23mr10763291pfp.42.1631532749096; Mon, 13 Sep 2021 04:32:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpV5ZgvV2xemjv5szxkZ46gDHyH7kyMF47RnbrEAaCmzBgtfdZV1h36tCZbBDJke6F1gkDAGNF9h5OIHNdeag= X-Received: by 2002:aa7:9ae9:0:b0:3f5:e1a7:db23 with SMTP id y9-20020aa79ae9000000b003f5e1a7db23mr10763269pfp.42.1631532748812; Mon, 13 Sep 2021 04:32:28 -0700 (PDT) MIME-Version: 1.0 References: <20210907121943.3498701-1-marcandre.lureau@redhat.com> <20210907121943.3498701-2-marcandre.lureau@redhat.com> In-Reply-To: From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Mon, 13 Sep 2021 15:32:17 +0400 Message-ID: Subject: Re: [RFC v3 01/32] RFC: docs: add supported host CPUs section To: Peter Maydell Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlureau@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000eecf2b05cbded15c" Received-SPF: pass client-ip=216.205.24.124; envelope-from=mlureau@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.398, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , "Daniel P. Berrange" , QEMU Developers , Stefan Hajnoczi , Markus Armbruster Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000eecf2b05cbded15c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Tue, Sep 7, 2021 at 4:34 PM Peter Maydell wrote: > On Tue, 7 Sept 2021 at 13:23, wrote: > > > > From: Marc-Andr=C3=A9 Lureau > > > > 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=C3=A9 Lureau > > --- > > 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 identif= y > > 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 --000000000000eecf2b05cbded15c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Tue, Sep 7, 2021 at 4:34 PM Pete= r Maydell <peter.maydell@lin= aro.org> wrote:
On Tue, 7 Sept 2021 at 13:23, <marcandre.lureau@redhat.com> wrote: >
> From: Marc-Andr=C3=A9 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=C3=A9 Lureau <marcandre.lureau@redhat.com> > ---
>=C2=A0 docs/about/build-platforms.rst | 28 ++++++++++++++++++++++++++++=
>=C2=A0 meson.build=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 2 +-
>=C2=A0 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/docs/about/build-platforms.rst b/docs/about/build-platfor= ms.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 identi= fy
>=C2=A0 currently shipped versions of software in various operating syst= ems,
>=C2=A0 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)
=C2=A0
> +=C2=A0 .. list-table::
> +=C2=A0 =C2=A0:header-rows: 1
> +
> +=C2=A0 =C2=A0* - CPU Family

=C2= =A0I'll change this to CPU Architecture

> +=C2=A0 =C2=A0 =C2=A0- Accelerators
> +=C2=A0 =C2=A0* - 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.
=C2=A0
> +=C2=A0 =C2=A0 =C2=A0- kvm, xen
> +=C2=A0 =C2=A0* - MIPS
> +=C2=A0 =C2=A0 =C2=A0- kvm
> +=C2=A0 =C2=A0* - PPC
> +=C2=A0 =C2=A0 =C2=A0- kvm
> +=C2=A0 =C2=A0* - RISC-V
> +=C2=A0 =C2=A0 =C2=A0-
> +=C2=A0 =C2=A0* - s390x
> +=C2=A0 =C2=A0 =C2=A0- kvm
> +=C2=A0 =C2=A0* - SPARC
> +=C2=A0 =C2=A0 =C2=A0-
> +=C2=A0 =C2=A0* - x86
> +=C2=A0 =C2=A0 =C2=A0- kvm, xen, hax, hvf (64 bit only), nvmm, whpx (6= 4 bit only)
> +
> +Other architectures are not actively maintained. They use the slow an= d
> +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<= /div>


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 pro= per 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 ?
<= div>=C2=A0
That could be really useful, but I am not up to th= e task at this point.

thanks

--000000000000eecf2b05cbded15c--