Hypercall for sleeping for some amount of time?

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.

Quoted 19 lines · 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?

Quoted 6 lines

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.

Quoted 5 lines · Stefan Fritsch

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.