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:
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
On Wed, Nov 23, 2022 at 11:41:03 +0000, Daniel P. Berrangé wrote: 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. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|