qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kashyap Chamarthy <kchamart@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH] cpu-models-x86.rst: Tidy up a couple of things
Date: Wed, 10 Nov 2021 14:51:47 +0100	[thread overview]
Message-ID: <YYvOc2n0IfLIm/Ue@paraplu> (raw)
In-Reply-To: <20211015152259.2948176-1-kchamart@redhat.com>

On Fri, Oct 15, 2021 at 05:22:59PM +0200, Kashyap Chamarthy wrote:
> - Remove stray texinfo syntax (remnants of texinfo to rST conversion)
> - Clarify the bit about long-term stable CPU models
> 
> TODO: In a future patch, include potential examples as discussed
>       here[1].
> 
> [1] https://lists.nongnu.org/archive/html/qemu-devel/2021-10/msg03411.html
>     -- On versioned CPU models, aliases, and machine types

Ping?

I'd also appreciate if anyone can also answer the two questions I raised
in the above thread[1].

> Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
> ---
> Eduardo/DanPB: I'm not 100% sure if my wording got it right; please give
> it a close reading to make sure I'm not making things worse.
> ---
>  docs/system/cpu-models-x86.rst.inc | 25 +++++++++++++++++--------
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/docs/system/cpu-models-x86.rst.inc b/docs/system/cpu-models-x86.rst.inc
> index 6e8be7d79b..e133753920 100644
> --- a/docs/system/cpu-models-x86.rst.inc
> +++ b/docs/system/cpu-models-x86.rst.inc
> @@ -25,7 +25,7 @@ Two ways to configure CPU models with QEMU / KVM
>      typically refer to specific generations of hardware released by
>      Intel and AMD.  These allow the guest VMs to have a degree of
>      isolation from the host CPU, allowing greater flexibility in live
> -    migrating between hosts with differing hardware.  @end table
> +    migrating between hosts with differing hardware.
>  
>  In both cases, it is possible to optionally add or remove individual CPU
>  features, to alter what is presented to the guest by default.
> @@ -47,11 +47,20 @@ defined. Traditionally most operating systems and toolchains would
>  only target the original baseline ABI. It is expected that in
>  future OS and toolchains are likely to target newer ABIs. The
>  table that follows illustrates which ABI compatibility levels
> -can be satisfied by the QEMU CPU models. Note that the table only
> -lists the long term stable CPU model versions (eg Haswell-v4).
> -In addition to whats listed, there are also many CPU model
> -aliases which resolve to a different CPU model version,
> -depending on the machine type is in use.
> +can be satisfied by the QEMU CPU models. Note that the table only lists
> +the long term stable CPU model versions (e.g. Haswell-v4, Haswell-v3).
> +CPU models without a version tag will alias to a CPU model with a
> +version tag, and the alias varies depending on the machine type.  In
> +addition to what is listed, there are also many CPU model aliases which
> +resolve to a different CPU model version, depending on the machine type
> +in use.
> +
> +The versioned CPU models (e.g. ``Cascadelake-Server-v4``,
> +``Broadwell-v4``) are long-term stable.  Further, when using a versioned
> +machine type (e.g. ``pc-q35-6.0``), instead of its generic alias
> +(``q35``), the CPU models that are associated with it are also long-term
> +stable.  This is because the CPUID features in the CPU models that are
> +part of a versioned machine type do not change.
>  
>  .. _ABI compatibility levels: https://gitlab.com/x86-psABIs/x86-64-ABI/
>  
> @@ -185,8 +194,8 @@ features are included if using "Host passthrough" or "Host model".
>    guest.  Instead, the host kernel uses it to populate the MDS
>    vulnerability file in ``sysfs``.
>  
> -  So it should only be enabled for VMs if the host reports @code{Not
> -  affected} in the ``/sys/devices/system/cpu/vulnerabilities/mds`` file.
> +  So it should only be enabled for VMs if the host reports ``Not
> +  affected`` in the ``/sys/devices/system/cpu/vulnerabilities/mds`` file.
>  
>  ``taa-no``
>    Recommended to inform that the guest that the host is ``not``
> -- 
> 2.31.1
> 

-- 
/kashyap



      reply	other threads:[~2021-11-10 13:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 15:22 [PATCH] cpu-models-x86.rst: Tidy up a couple of things Kashyap Chamarthy
2021-11-10 13:51 ` Kashyap Chamarthy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YYvOc2n0IfLIm/Ue@paraplu \
    --to=kchamart@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).