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