Hypercall for sleeping for some amount of time?

Hypercall for sleeping for some amount of time?

[Stefan Fritsch]

Hi,

there are situations where a guest needs to wait, but has interrupts 
disabled.  Usually this is done by polling in a tight loop, which is a 
waste of CPU cycles on a virtualized system. Therefore I propose to 
add a hypercall to KVM that allows the guest to yield the CPU for a 
specified amount of time.

One significant use case is the guest sitting in a kernel debugger and 
polling for user input. But I expect that there are other situations 
where such a hypercall could be useful, for example during hardware 
detection at startup.

What do you think about this idea?

What would be the preferred interface for such a hypercall? Using 
vmcall like KVM_HC_*, or MSR write, or even a simple IO port write? Is 
there a way to make this architecture independent?

For detection, at least a new bit in KVM_CPUID_FEATURES would be 
necessary.  Does one also need more information, like the minimum 
supported delay and the expected granularity of the delay? Also, 
should the call be simply "best effort" or should it guarantee that it 
sleeps for at least the requested time? I think keeping it simple at 
first would be best.

Cheers,
Stefan

Re: Hypercall for sleeping for some amount of time?

[Paolo Bonzini]

On 23/01/2015 10:40, Stefan Fritsch wrote:
> Hi,
> 
> there are situations where a guest needs to wait, but has interrupts 
> disabled.  Usually this is done by polling in a tight loop, which is a 
> waste of CPU cycles on a virtualized system. Therefore I propose to 
> add a hypercall to KVM that allows the guest to yield the CPU for a 
> specified amount of time.
> 
> One significant use case is the guest sitting in a kernel debugger and 
> polling for user input. But I expect that there are other situations 
> where such a hypercall could be useful, for example during hardware 
> detection at startup.
> 
> What do you think about this idea?
> 
> What would be the preferred interface for such a hypercall? Using 
> vmcall like KVM_HC_*, or MSR write, or even a simple IO port write? Is 
> there a way to make this architecture independent?
> 
> For detection, at least a new bit in KVM_CPUID_FEATURES would be 
> necessary.  Does one also need more information, like the minimum 
> supported delay and the expected granularity of the delay? Also, 
> should the call be simply "best effort" or should it guarantee that it 
> sleeps for at least the requested time? I think keeping it simple at 
> first would be best.

I think a platform device similar to drivers/platform/x86/pvpanic.c
would be best.  That would be a simple IO port write (milliseconds?),
with the port described in ACPI.

Paolo

Re: Hypercall for sleeping for some amount of time?

[Stefan Fritsch]

On Friday 23 January 2015 10:53:00, Paolo Bonzini wrote:
> On 23/01/2015 10:40, Stefan Fritsch wrote:
> > Hi,
> > 
> > there are situations where a guest needs to wait, but has
> > interrupts disabled.  Usually this is done by polling in a tight
> > loop, which is a waste of CPU cycles on a virtualized system.
> > Therefore I propose to add a hypercall to KVM that allows the
> > guest to yield the CPU for a specified amount of time.
> > 
> > One significant use case is the guest sitting in a kernel debugger
> > and polling for user input. But I expect that there are other
> > situations where such a hypercall could be useful, for example
> > during hardware detection at startup.
> > 
> > What do you think about this idea?
> > 
> > What would be the preferred interface for such a hypercall? Using
> > vmcall like KVM_HC_*, or MSR write, or even a simple IO port
> > write? Is there a way to make this architecture independent?
> > 
> > For detection, at least a new bit in KVM_CPUID_FEATURES would be
> > necessary.  Does one also need more information, like the minimum
> > supported delay and the expected granularity of the delay? Also,
> > should the call be simply "best effort" or should it guarantee
> > that it sleeps for at least the requested time? I think keeping
> > it simple at first would be best.
> 
> I think a platform device similar to drivers/platform/x86/pvpanic.c
> would be best.  That would be a simple IO port write
> (milliseconds?), with the port described in ACPI.

Wasn't there some issue that Windows guests would then ask for a 
driver? AIUI, pvpanic has been disabled by default for this reason. 
Also, it would be nice if simplistic bootloaders without ACPI support 
would also be able to use the feature.

Cheers,
Stefan

Re: Hypercall for sleeping for some amount of time?

[Paolo Bonzini]

On 23/01/2015 12:18, Stefan Fritsch wrote:
> Wasn't there some issue that Windows guests would then ask for a 
> driver? AIUI, pvpanic has been disabled by default for this reason. 
> Also, it would be nice if simplistic bootloaders without ACPI support 
> would also be able to use the feature.

That was only XP and perhaps 2003.  I think this is a very specialized
usecase.  In most cases you can use hlt.

Paolo

Re: Hypercall for sleeping for some amount of time?

[Stefan Fritsch]

On Friday 23 January 2015 12:58:20, Paolo Bonzini wrote:
> On 23/01/2015 12:18, Stefan Fritsch wrote:
> > Wasn't there some issue that Windows guests would then ask for a
> > driver? AIUI, pvpanic has been disabled by default for this
> > reason.
> > Also, it would be nice if simplistic bootloaders without ACPI
> > support would also be able to use the feature.
> 
> That was only XP and perhaps 2003.  I think this is a very
> specialized usecase.  In most cases you can use hlt.

OK, I will give it a try.

Stefan