[libvirt] Question about using cpu mode "host-model" while providing a cpu model name

[Collin Walling]

On 05/17/2018 03:28 PM, Jiri Denemark wrote:
> On Wed, May 09, 2018 at 13:36:55 +0200, Halil Pasic wrote:
>>
>>
>> On 05/09/2018 12:41 PM, Jiri Denemark wrote:
>>> On Tue, May 08, 2018 at 10:44:22 -0400, Collin Walling wrote:
>>>> Hi
>>>>
>>>> I have noticed something that may be misconstrued regarding the libvirt domain xml format
>>>> for defining a cpu model. There seems to be a misalignment where the libvirt documentation
>>>> states something that is not supported, but libvirt itself gives no clear indication of
>>>> such. This is regarding the cpu mode "host-model" and providing a cpu model name between
>>>> the <model> tags.
>>>>
>>>> >From the libvirt docs under header "CPU model and topology" paragraph "cpu" subparagraph
>>>> "host-model", the following rule is defined (bolded or between asterisks):
>>>>
>>>> "... The match attribute can't be used in this mode. *Specifying CPU model is not supported*
>>>> either, but model's fallback attribute may still be used. ..."
>>>>
>>>> https://libvirt.org/formatdomain.html#elementsCPU
>>>>
>>>> The above rule reads as "if mode is 'host-model' (and the architecture is not PowerPC) then
>>>> specifying a model name should not be allowed". However, this is not the observed behavior.
>>>> For example, I can define and start a guest with the following xml snippet without any issues:
>>>>
>>>> <cpu mode='host-model'>
>>>>      <model>cpu-name</model>
>>>> </cpu>
>>>>
>>>> Which seems to contradict what the documentation states.
>>>
>>> It's not forbidden for compatibility reasons. Old libvirt used to fill
>>> in the <model>...</model> in <cpu mode='host-model'></cpu> during
>>> migration and save/restore so that the destination would know the actual
>>> CPU the domain was started with. We changed this so that host-model
>>> automatically turns into mode='custom' CPU when a domain starts, but we
>>> still need to support parsing the XML whare mode='host-model' and
>>> <model></model> are used at the same time. When a domain is migrated,
>>> libvirt will turn the incoming host-model into custom mode. Otherwise
>>> the specified model will just be ignored.
>>>
>>> Jirka
>>>
>>
>> Thank you very much for your explanation. AFAIU we already differentiate between:
>> a) 'incoming migration' (~ transient domain definition) --> convert to 'custom'
>> b) 'otherwise' (~ persistent domain definition) --> ignored.
> 
> Right, but this differentiation is not done in the parser, so we still
> need to keep the code there. However, we should be able to do so in the
> appropriate PostParse function.
> 
>> Thus b') persistent domain definition --> error or warn would
>> not break the scenario you described (again AFAIU).
> 
> I guess we could fail when a new domain is defined, but we must be extra
> careful to not break backward compatibility. Alternatively we could just
> drop the model name from CPU definition when a new domain is defined
> (and log a warning) as suggested by Boris in another email. This
> approach would be probably a bit better wrt backward compatibility since
> everything would keep working.
> 

I know it has been a while, but I have some time set aside now that I can use 
to look into this unless someone else feels better about tackling it.

Also my apologies for the long silence.


-- 
Respectfully,
- Collin Walling