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.
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 :|