On Thu, Sep 26, 2019 at 18:43:05 -0300, Eduardo Habkost wrote: > The pconfig feature never worked, and adding "pconfig=off" to the > QEMU command-line triggers a regression in QEMU 3.1.1 and 4.0.0. > > Signed-off-by: Eduardo Habkost <ehabkost@xxxxxxxxxx> > --- > I'm sending this as an RFC because I couldn't test it properly, > and because I don't know what are the consequences of changing > cpu_map between libvirt versions. > --- > src/cpu_map/x86_Icelake-Server.xml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/cpu_map/x86_Icelake-Server.xml b/src/cpu_map/x86_Icelake-Server.xml > index fb15977a59..188a781282 100644 > --- a/src/cpu_map/x86_Icelake-Server.xml > +++ b/src/cpu_map/x86_Icelake-Server.xml > @@ -56,7 +56,9 @@ > <feature name='pat'/> > <feature name='pcid'/> > <feature name='pclmuldq'/> > - <feature name='pconfig'/> > + <!-- 'pconfig' was added by accident in QEMU 3.1.0 but never worked. > + It was removed in QEMU 3.1.1 and 4.0.0. See QEMU commits > + 76e5a4d58357 and 712f807e1965 for details --> > <feature name='pdpe1gb'/> > <feature name='pge'/> > <feature name='pku'/> IIUC this never worked and a domain started with Icelake-Server CPU model would actually end up running with pconfig=off, right? In that case removing pconfig from Icelake-Server would not cause any issues when a domain is started. However, I'm afraid migration would be broken. If a domain is started by new libvirt (with this patch in) using Icelake-Server CPU model possibly with additional features added or removed, but without pconfig being explicitly mentioned, libvirt would not disable pconfig when updating active definition according to the actual CPU created by QEMU. This is because libvirt did not ask for pconfig (either explicitly or implicitly via the CPU model). When such domain gets migrated to an older libvirt (which thinks pconfig is part of Icelake-Server), it will complain that QEMU disabled pconfig while the source domain was running with pconfig enabled (which is an incorrect result caused by inconsistent view of the CPU model). Thus we would need to add a hack which would explicitly disable pconfig in the domain definition used for migration to make sure the destination libvirtd knows pconfig was disabled. New libvirt would just drop the disabled pconfig feature from the CPU definition before starting a domain. [1] From this point of view we could just keep the CPU model in libvirt untouched. This way pconfig would always be explicitly disabled when a domain is running and the host-model CPU definition would also show it as explicitly disabled. [2] However starting a domain with Icelake-Server so that it can be migrated or saved/restored on QEMU in 3.1.1 and 4.0.0 would be impossible. This can be solved by a different hack, which would drop pconfig=off from QEMU command line. [3] But if pconfig was removed from QEMU and never returned back, we could remove it from any domain XML we see (virQEMUCapsCPUFilterFeatures mentions several other features which we handle this way). That said, I think [3] would be the best option. But if QEMU cannot or doesn't want to remove pconfig completely, I'd go with [1] as the hack in [2] would be too ugly and confusing. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
