[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02848f20-ecf9-550b-9b55-0260b05f6ecd@redhat.com>
Date: Mon, 20 Apr 2020 23:07:24 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Jon Cargille <jcargill@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: David Matlack <dmatlack@...gle.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kvm: add capability for halt polling
On 20/04/20 20:47, Jon Cargille wrote:
> Great question, Vitaly. We actually implemented this as a per-VCPU property
> initially; however, our user-space implementation was only using it to apply
> the same value to all VCPUs, so we later simplified it on the advice of
> Jim Mattson. If there is a consensus for this to go in as per-VCPU rather
> than per-VM, I'm happy to submit that way instead. The per-VM version did
> end up looking simpler, IMO.
Yeah, I am not sure what the usecase would be for per-vCPU halt polling.
You could perhaps disable halt polling for vCPUs that are not placed on
isolated physical CPUs (devoting those vCPUs to housekeeping), but it
seems to me that this would be quite hard to get right. But in that
case you would probably prefer to disable HLT vmexits completely, rather
than use halt polling.
Paolo
Powered by blists - more mailing lists