From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/3] [PATCH] kvmclock - the host part. Date: Sat, 12 Jan 2008 22:49:30 +0200 Message-ID: <478927DA.3000800@qumranet.com> References: <12000570563874-git-send-email-gcosta@redhat.com> <12000570732755-git-send-email-gcosta@redhat.com> <12000570802212-git-send-email-gcosta@redhat.com> <47878F8A.4010506@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, jeremy-TSDbQ3PG+2Y@public.gmane.org, Glauber de Oliveira Costa To: Anthony Liguori Return-path: In-Reply-To: <47878F8A.4010506-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 Anthony Liguori wrote: > Glauber de Oliveira Costa wrote: > >> This is the host part of kvm clocksource implementation. As it does >> not include clockevents, it is a fairly simple implementation. We >> only have to register a per-vcpu area, and start writting to it periodically. >> >> The area is binary compatible with xen, as we use the same shadow_info structure. >> >> diff --git a/include/asm-x86/kvm_para.h b/include/asm-x86/kvm_para.h >> index c6f3fd8..abe412a 100644 >> --- a/include/asm-x86/kvm_para.h >> +++ b/include/asm-x86/kvm_para.h >> @@ -1,5 +1,6 @@ >> #ifndef __X86_KVM_PARA_H >> #define __X86_KVM_PARA_H >> +#include >> > > Can we abstract that out into a neutral header instead of including the > Xen headers directly in KVM. Please rename the structure too to > something neutral. > > Including something as generic as xen/interface/xen.h when CONFIG_XEN > may not be set is not a good thing, I believe. > Well, one of the motivations behind this is to actually supply a Xen clock to Xen guests. So maybe we can call the feature a "kvm xenclock" instead and feel justified in including Xen headers. However, you are probably right in that we are getting into a dependency and kconfig hell we do not yet deserve. Not even mentioning that CONFIG_XEN is a guest thing while kvmclock is also a host thing. So we are probably better of using a non-Xen structure that accidentally happens to be binary compatible with the Xen interface. Stranger things have happened. If we agree on this, please define _only_ the time-related parts so we have a decoupled interface. We'll need two msrs: one for wc and one for vcpu time. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace