From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Fritsch Subject: Re: Hypercall for sleeping for some amount of time? Date: Fri, 23 Jan 2015 12:18:07 +0100 Message-ID: <1644320.OpRzVAVdBs@k> References: <1592884.UZW4Xi8OkR@k> <54C219FC.7050203@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: kvm@vger.kernel.org, Gleb Natapov To: Paolo Bonzini Return-path: Received: from eru.sfritsch.de ([188.40.99.202]:45478 "EHLO eru.sfritsch.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755152AbbAWLSQ (ORCPT ); Fri, 23 Jan 2015 06:18:16 -0500 In-Reply-To: <54C219FC.7050203@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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