On Wed, May 16, 2018 at 12:33:50PM -0300, Eduardo Habkost wrote: > On Wed, May 16, 2018 at 06:13:17PM +0300, Michael S. Tsirkin wrote: > > On Wed, May 16, 2018 at 05:04:41PM +0200, Paolo Bonzini wrote: > > > On 16/05/2018 16:22, Michael S. Tsirkin wrote: > > > >> kvm-hint-dedicated=on only sets the CPUID bit, which Linux for example > > > >> uses that to disable pv spinlocks. "-realtime dedicated-cpus=on" only > > > >> disables the vmexits. You can use the two independently. > > > > > > > > But when would you want to use the two independently? > > > > > > 1) For testing > > > > > > 2) When some of your QEMUs are too old to support kvm-hint-dedicated=on, > > > you may still want to use -realtime dedicated-cpus=on to get better > > > performance on the new one. > > > > > > Paolo > > > > For the second purpose, can't we handle this using machine types? > > Machine-type compatibility code deals with defaults when options > are omitted, not for making the meaning of explicit options > depend on the machine-type. > > e.g. having "-machine pc-q35-2.11 -cpu ...,+kvm-hint-dedicated=on" > not expose the CPUID bit that was explicitly requested in the > command-line would be a bad idea. Why? We have machine type affecting guest visible device behaviours for years. > -- > Eduardo
