Re: [libvirt] [RFC] cpu_map: Remove pconfig from Icelake-Server CPU model
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