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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
