On Mon, Sep 30, 2019 at 17:16:27 +0200, Paolo Bonzini wrote:
On 30/09/19 16:31, Hu, Robert wrote:
This might be a problem if there are plans to eventually make KVM support pconfig, though. Paolo, Robert, are there plans to support pconfig in KVM in the future? [Robert Hoo] Thanks Eduardo for efforts in resolving this issue, introduced from my Icelake CPU model patch. I've no idea about PCONFIG's detail and plan. Let me sync with Huang, Kai and answer you soon.
It's really, really unlikely. It's possible that some future processor overloads PCONFIG in such a way that it will become virtualizable, but not IceLake.
I guess, the likelihood of this happening would be similar to reintroducing other features, such as osxsave or ospke, right?
Would it make sense for libvirt to treat absent CPU flags as "default off" during migration, so that it can leave out the flag in the command line if it's off? If it's on, libvirt would pass pconfig=on as usual. This is a variant of [2], but more generally applicable:
[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.
The domain XML does not contain a complete list of all CPU features. Features which are implicitly included in a CPU model are not listed in the XML. Count in the differences in libvirt's vs QEMU's definitions of a particular CPU model and you can see feat=off cannot be mechanically dropped from the command line as the CPU model itself could turn it on by default and thus feat=off is not redundant. Jirka