Re: Question about using cpu mode "host-model" while providing a cpu model name

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/09/2018 01:35 PM, Kashyap Chamarthy wrote:
On Tue, May 08, 2018 at 10:44:22AM -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>

After starting the guest, you still see the same as above when you do
`virsh dumpxml $GUEST`?  Also does the "cpu-name" of your choice really
shows up when check the QEMU command-line for the guest?

After the domain is defined but not started:
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'>cpu-name</model>
  </cpu>
After the defined domain is started:
  <cpu mode='custom' match='exact' check='partial'>
    <model fallback='forbid'>z13.2-base</model>
    <feature policy='require' name='aen'/>
    <feature policy='require' name='aefsi'/>
    <feature policy='require' name='msa5'/>
    <feature policy='require' name='msa4'/>
    <feature policy='require' name='msa3'/>
    <feature policy='require' name='msa2'/>
    <feature policy='require' name='msa1'/>
    <feature policy='require' name='sthyi'/>
    <feature policy='require' name='edat'/>
    <feature policy='require' name='ri'/>
    <feature policy='require' name='edat2'/>
    <feature policy='require' name='vx'/>
    <feature policy='require' name='ipter'/>
    <feature policy='require' name='esop'/>
    <feature policy='require' name='cte'/>
    <feature policy='require' name='bpb'/>
    <feature policy='require' name='ppa15'/>
    <feature policy='require' name='zpci'/>
    <feature policy='require' name='sea_esop2'/>
    <feature policy='require' name='te'/>
    <feature policy='require' name='cmm'/>
  </cpu>

and of course the cpu_name does not show up in the qemu command line.
The question is if the model could not simply be ignored in the define scenario resulting in
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>
which also gets generated when just defining the domain with
  <cpu mode='host-model'/>


--
Mit freundlichen Grüßen/Kind regards
   Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux