From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [RFC] Paravirt timer for KVM Date: Fri, 12 Oct 2007 16:55:37 -0500 Message-ID: <1192226137.14891.111.camel@basalt> References: <5d6222a80710120908s6b1f5845head84e7b7a463cd1@mail.gmail.com> <1192218507.14891.18.camel@basalt> <470FD2CA.1000702@codemonkey.ws> Reply-To: Hollis Blanchard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , Jeremy Fitzhardinge , Avi Kivity To: Anthony Liguori Return-path: In-Reply-To: <470FD2CA.1000702-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Fri, 2007-10-12 at 15:02 -0500, Anthony Liguori wrote: > Hollis Blanchard wrote: > > On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote: > > > >> +config KVM_CLOCK > >> + bool "KVM paravirtualized clock" > >> + depends on PARAVIRT && GENERIC_CLOCKEVENTS > >> + help > >> + Turning on this option will allow you to run a paravirtualized clock > >> + when running over the KVM hypervisor. Instead of relying on a PIT > >> + (or probably other) emulation by the underlying device model, the host > >> + provides the guest with timing infrastructure, as time of day, and > >> + timer expiration. > >> > > > > I must have missed earlier discussion on this topic, so I'm left > > wondering... what's the point? What's wrong with PIT (et al) emulation? > > > > There are three separate reasons, that I know of, to have a PV timer. > > 1) the PIT is periodic. a PV timer can offer a one shot timer which > enables dynticks. Obviously people have figured out how to do dynticks on real x86 hardware, so I don't accept this reason. :) > 2) the TSC would have to be used as a clocksource. You don't know the > frequency which is the first problem with using the TSC but some systems > have a TSC that changes frequencies. A PV time source gives you more > stable clocksource (although as in glommer's patch, when the TSC can be > used, it's better to use it). As I understand it, the TSC is based on CPU frequency, which changes with power management. Architectural bug. However, PV time still doesn't help here: * The TSC is _user_ accessible, so PV time support in the guest kernel doesn't solve the problem. * It looks like external agents can perform out-of-kernel frequency scaling on x86 (at least I see options for it on IBM blades). So there must already exist some mechanism for a kernel to be informed that the TSC frequency has been changed. > 3) a PV clock can support stolen time calculation which there really > isn't a concept of with emulation. This is true, and I know other platforms support this functionality. I think it's mostly useful for process time accounting. Is that actually supported in this patch? -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/