Re: [RFC PATCH 1/1] i386: Remove features from Epyc-Milan cpu

[Igor Mammedov]

On Mon, 31 Jan 2022 17:18:04 -0300
Leonardo Bras Soares Passos <leobras@redhat.com> wrote:

> On Mon, Jan 31, 2022 at 3:04 PM Daniel P. Berrangé <berrange@redhat.com> 
> wrote:
> >
> > On Mon, Jan 31, 2022 at 02:56:38PM -0300, Leonardo Bras Soares Passos 
> > wrote:  
> > > Hello Daniel,
> > >
> > > On Mon, Jan 31, 2022 at 6:08 AM Daniel P. Berrangé <berrange@redhat.com> 
> > > wrote:  
> > > >
> > > > CC'ing  Babu Moger who aded the Milan CPU model.
> > > >
> > > > On Sat, Jan 29, 2022 at 07:23:37AM -0300, 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.  
> > > >
> > > > Babu,  can you give some insight into availability of erms / fsrm
> > > > features across the EPYC 3rd gen CPU line. Is this example missing
> > > > erms/fsrm an exception, or common place ?
> > > >  
> > > > >
> > > > > Signed-off-by: Leonardo Bras <leobras@redhat.com>
> > > > > ---
> > > > >
> > > > > Does this make sense? Or maybe I am missing something here.
> > > > >
> > > > > Having a kvm guest running with a feature bit, while the host
> > > > > does not support it seems to cause a possible break the guest.  
> > > >
> > > > The guest won't see the feature bit - that warning message from QEMU
> > > > is telling you that it did't honour the request to expose
> > > > erms / fsrm - it has dropped them from the CPUO exposed to the guest.  
> > >
> > > Exactly.
> > > What I meant here is:
> > > 1 - Host with these feature bits start a VM with EPYC-Milan cpu (and
> > > thus have those bits enabled)
> > > 2 - Guest is migrated to a host such as the above, which does not
> > > support those features (bits disabled), but does support EPYC-Milan
> > > cpus (without those features).
> > > 3 - The migration should be allowed, given the same cpu types. Then
> > > either we have:
> > > 3a : The guest vcpu stays with the flag enabled (case I tried to
> > > explain above), possibly crashing if the new feature is used, or
> > > 3b: The guest vcpu disables the flag due to incompatibility,  which
> > > may make the guest confuse due to cpu change, and even end up trying
> > > to use the new feature on the guest, even if it's disabled.  
> >
> > Neither should happen with a correctly written mgmt app in charge.
> >
> > When launching a QEMU process for an incoming migration, it is expected
> > that the mgmt app has first queried QEMU on the source to get the precise
> > CPU model + flags that were added/removed on the source. The QEMU on
> > the target is then launched with this exact set of flags, and the
> > 'check' flag is also set for -cpu. That will cause QEMU on the target
> > to refuse to start unless it can give the guest the 100% identical
> > CPUID to what has been requested on the CLI, and thus matching the
> > source.
> >
> > Libvirt will ensure all this is done correctly. If not using libvirt
> > then you've got a bunch of work to do to achieve this. It certainly
> > isn't sufficient to merely use the same plain '-cpu' arg that the
> > soruce was original booted with, unless you have 100% identical
> > hardware, microcode, and software on both hosts, or the target host
> > offers a superset of features.  
> 
> Oh, that is very interesting! Thanks for sharing!
> 
> Well, then at least one unexpected scenario should happen:
> - VM with EPYC-Milan cpu, created in source host
> - Source host with EPYC-Milan cpu. Support for 'extra features'
> enabled ( erms / fsrm in this ex.)
> - Target host with EPYC-Milan cpu. No support for 'extra features'.
> Since the VM will be created with support for 'extra features', trying
> to migrate from source host to target host should fail, right?
> 
> Which is, IMHO, odd. I imagine questions like:
> - "How does a host with EPYC-Milan cpu does not offer support to
> receive a live migration of some VMs with EPYC-Milan cpu?", or even
> - "If I can create a VM with EPYC-Milan cpu on that host, why can't I
> receive (via migration) some VMs with EPYC-Milan CPU ?"

As Daniel already explained, libvirt will check compatibility for user.

If you are trying to run QEMU manually, and wish features
for specific CPU model to be enforced, you shall use
  -cpu EPYC,enforce=on
flag when starting VMs, that will make QEMU exit with error
if it can't create cpu model with all its features on a given host.

(the warnings was telling you what's wrong with cpu model on
target host, so you shouldn't expect migration to work if
source host doesn't spew the exact same set of warnings)

> But I am new to live migration, so maybe I am getting something wrong
> regarding the cpu-model idea.
> 
> Best regards,
> Leo
> 
> 
> 
> >
> >
> > 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 
> > :|
> >  
> 
>