On 23/11/22 6:00 pm, Daniel P. Berrangé wrote:
On Wed, Nov 23, 2022 at 05:58:41PM +0530, manish.mishra wrote:
On 23/11/22 5:44 pm, Daniel P. Berrangé wrote:
On Wed, Nov 23, 2022 at 12:51:39PM +0100, Jiri Denemark wrote:
On Wed, Nov 23, 2022 at 11:41:03 +0000, Daniel P. Berrangé wrote:
Why can't it just use the exsting QEMU passthrough syntax we have.
I don't think we should be adding specifial support just for CPUs
That would be nice, but the QEMU passthrough syntax cannot be used for
changing options that libvirt already passes to QEMU. So using it would
likely result in two separate -cpu options on QEMU command line. And it
would not rule out the CPU verification code in libvirt. Remember, we
add a default -cpu model in case there's none configured in the XML.
Two -cpu options isn't a problem, the latter will override the former,
which is fine from the level of support intended for QEMU passthrough
usage.
For the libvirt checking, isn't the 'check=none' attr sufficient
to skip checks libvirt does.
With regards,
Daniel
Actually even within check='none' libvirt does few checks e.g.
virCPUValidateFeatures if feature string passed is proper and
defined in libvirt. We could extend check='none' to remove even
these kind of things. So Jiri suggested that making such kind
of changes in general path is not good idea so discussion went
to using separate cpu class <qemu:cpu>.
There is no need to remove any such check, as you wouldn't
be specifying any <cpu> element with custom features set,
so the virCPUValidateFeuatres check should not be creating
any problems at that point.
oh i see you meant something like this,
<cpu mode='custom' match='exact' check='none'>
<numa>
<cell id='0' cpus='0-239' memory='8388608' unit='KiB' memAccess='shared'/>
</numa>
</cpu>
<qemu:commandline>
<qemu:arg value='-cpu'/>
<qemu:arg value='enforce,Icelake-v4,x2apic=on,hv-time,kvm-pv-eoi=on'/>
</qemu:commandline>
oh ok gives us sometime to evaluate this will revert soon, I am more worried
about if we have to deal with other cpu related things too other than just cpu
feature and model. Our current usecase was only around cpu features and cpu
model :).
Thanks
Manish Mishra
With regards,
Daniel
