Re: [PATCH 0/3] KVM: Tie MWAIT/HLT/PAUSE interception to initially disabled capabilities

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 29, 2017 at 09:43:22AM +0100, Paolo Bonzini wrote:
> On 29/11/2017 01:20, Michael S. Tsirkin wrote:
> > On Wed, Nov 29, 2017 at 01:07:32AM +0100, Paolo Bonzini wrote:
> >> On 28/11/2017 15:08, Michael S. Tsirkin wrote:
> >>> I think guests still want some way to halt when
> >>> giving up CPU for a long time.
> >>>
> >>> If you are not worried about guests entering low power states,
> >>> then you only need MWAIT and maybe PAUSE.
> >>>
> >>> HLT within guest only makes sense if you do not want to
> >>> allow guest to enter power state.
> >>>
> >>> If you don't exit on any of these, you want some other way
> >>> to actually halt the VCPU.
> >>
> >> If you want to do something in userspace, send a signal.  Otherwise, it
> >> doesn't really matter (if you have a dedicated physical CPU) whether the
> >> task is runnable or not, as long as the CPU isn't in C0.
> > 
> > If VCPU wants to give up its timeslice, how is it supposed to do it
> > if all exits are blocked?
> 
> It's the host userspace who told KVM it doesn't care.  Why would the
> vCPU care?
> 
> Paolo

I guess you assume this will only be used for dedicated host CPUs.
Fair enough. And please do not take this as critique of the patchset,
I'm just trying to look a bit further.

My assumption is that some userspace might want to enable mwait
exiting due to latency concerns. To get low latency wakeups
it might also want to disable HLT exiting. How does one
then give up the timeslice if it's known to be halted for a long time?

I guess we could allow userspace to register an address,
IO at that address would halt the VCPU.


-- 
MST