qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: David Edmondson <david.edmondson@oracle.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [RFC PATCH 1/1] i386: Remove features from Epyc-Milan cpu
Date: Mon, 31 Jan 2022 18:06:48 +0000	[thread overview]
Message-ID: <YfglOKxhkn2nTtCN@redhat.com> (raw)
In-Reply-To: <cunee4orwbh.fsf@oracle.com>

On Mon, Jan 31, 2022 at 11:14:42AM +0000, David Edmondson wrote:
> On Saturday, 2022-01-29 at 07:23:37 -03, Leonardo Bras wrote:
> 
> > While trying to bring a VM with EPYC-Milan cpu on a host with
> > EPYC-Milan cpu (EPYC 7313), the following warning can be seen:
> >
> > qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9]
> > qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EDX.fsrm [bit 4]
> >
> > Even with this warning, the host goes up.
> >
> > Then, grep'ing cpuid output on both guest and host, outputs:
> >
> > extended feature flags (7):
> >       enhanced REP MOVSB/STOSB                 = false
> >       fast short REP MOV                       = false
> >       (simple synth)  = AMD EPYC (3rd Gen) (Milan B1) [Zen 3], 7nm
> >    brand = "AMD EPYC 7313 16-Core Processor               "
> >
> > This means that for the same -cpu model (EPYC-Milan), the vcpu may or may
> > not have the above feature bits set, which is usually not a good idea for
> > live migration:
> > Migrating from a host with these features to a host without them can
> > be troublesome for the guest.
> >
> > Remove the "optional" features (erms, fsrm) from Epyc-Milan, in order to
> > avoid possible after-migration guest issues.
> >
> > Signed-off-by: Leonardo Bras <leobras@redhat.com>
> > ---
> >
> > Does this make sense? Or maybe I am missing something here.
> 
> We have encountered some Milan CPUs (7J13) that did not initially
> declare support for either ERMS or FSRM.
> 
> A firmware update caused these features to appear, which definitely
> causes potential problems with migration of VMs from hosts with updated
> firmware to those without.
> 
> It would be interesting to know if there is any expectation that the
> features might be enabled on the 7313 CPUs that you have with a future
> firmware update.
> 
> I *think* that the expectation is that Milan CPUs will have the
> features, and if that is correct then they should remain present in the
> EPYC-Milan definition on QEMU.

Agreed, if this is just a case of outdated firmware, then I think it
is a non-issue for our CPU model definition.  Libvirt will ensure
migration compatibility by launching the target QEMU with a -cpu
arg that results in a model that matches the source QEMU exactly.

It is merely a slight annoyance if someone launches a VM on a host
with new firmware and tries to migrate to a host with old firmware.
In that case though the answer is really to upgrade the firmware.

> > Having a kvm guest running with a feature bit, while the host
> > does not support it seems to cause a possible break the guest.
> 
> As Daniel said, this should not happen in this case.
> 
> >  target/i386/cpu.c | 5 +----
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index aa9e636800..a4bbd38ed0 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -4160,12 +4160,9 @@ static const X86CPUDefinition builtin_x86_defs[] = {
> >              CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_AVX2 |
> >              CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_RDSEED |
> >              CPUID_7_0_EBX_ADX | CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_CLFLUSHOPT |
> > -            CPUID_7_0_EBX_SHA_NI | CPUID_7_0_EBX_CLWB | CPUID_7_0_EBX_ERMS |
> > -            CPUID_7_0_EBX_INVPCID,
> > +            CPUID_7_0_EBX_SHA_NI | CPUID_7_0_EBX_CLWB | CPUID_7_0_EBX_INVPCID,
> >          .features[FEAT_7_0_ECX] =
> >              CPUID_7_0_ECX_UMIP | CPUID_7_0_ECX_RDPID | CPUID_7_0_ECX_PKU,
> > -        .features[FEAT_7_0_EDX] =
> > -            CPUID_7_0_EDX_FSRM,
> >          .features[FEAT_XSAVE] =
> >              CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC |
> >              CPUID_XSAVE_XGETBV1 | CPUID_XSAVE_XSAVES,
> 
> dme.
> -- 
> I don't care 'bout your other girls, just be good to me.
> 
> 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



      reply	other threads:[~2022-01-31 18:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-29 10:23 [RFC PATCH 1/1] i386: Remove features from Epyc-Milan cpu Leonardo Bras
2022-01-31  9:07 ` Daniel P. Berrangé
2022-01-31 17:56   ` Leonardo Bras Soares Passos
2022-01-31 18:03     ` Daniel P. Berrangé
2022-01-31 20:18       ` Leonardo Bras Soares Passos
2022-01-31 23:26         ` Babu Moger
2022-02-01  9:20           ` Dr. David Alan Gilbert
2022-02-01  8:13         ` Igor Mammedov
2022-02-01  9:18         ` Daniel P. Berrangé
2022-01-31 11:14 ` David Edmondson
2022-01-31 18:06   ` Daniel P. Berrangé [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=YfglOKxhkn2nTtCN@redhat.com \
    --to=berrange@redhat.com \
    --cc=david.edmondson@oracle.com \
    --cc=qemu-devel@nongnu.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).