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

["Daniel P. Berrangé" <berrange@redhat.com>]

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.


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 :|