Re: [kvm-devel] [PATCH 2/3] [PATCH] kvmclock - the host part.

[Avi K. <av...@qu...>]

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 <xen/interface/xen.h>
>>     
>
> 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.