qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RESEND v2] i386/kvm: add support for KVM_CAP_X86


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH RESEND v2] i386/kvm: add support for KVM_CAP_X86_DISABLE_EXITS
Date: Wed, 16 May 2018 14:20:22 -0300
User-agent: Mutt/1.9.2 (2017-12-15)

On Wed, May 16, 2018 at 07:21:04PM +0300, Michael S. Tsirkin wrote:
> 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.

Do you have an example where a machine-type overrides an option
explicitly set by the user?

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]