[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 1/1] i386: Remove features from Epyc-Milan cpu
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC PATCH 1/1] i386: Remove features from Epyc-Milan cpu |
Date: |
Mon, 31 Jan 2022 18:03:34 +0000 |
User-agent: |
Mutt/2.1.5 (2021-12-30) |
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 :|
Re: [RFC PATCH 1/1] i386: Remove features from Epyc-Milan cpu, David Edmondson, 2022/01/31