Re: [Disscussion] Moving x86 code out of kvm.h

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Zhang, Xiantao wrote:
>>> For driver/kvm/kvm.h,  I have a proposal before in mailing list.  In
>>> my proposal, we can split x86-specific code of kvm.h into current
>>> x86.h, and make code in kvm.h as common. Then, we rename kvm.h to
>>> kvm_comm.h, and also rename x86.h to kvm-x86.h, and meantime
>>> kvm-x86.h would include kvm_comm.h. At compile time, we can make
>>> symbol link for changing kvm-x86.h to kvm.h.  So, it should be more
>>> portable, because different archs can define its kvm-$arch.h to hold
>>> its arch-specific code. 
>>>
>>>       
>> I prefer not to have dynamic symlinks, it's too tricky.
>>
>> What's wrong with just the first part, x86.h which includes kvm.h?
>> x86.c will include x86.h, and arch neutral files will include kvm.h.
>>     
>
> I think it may have issues. For example, where do we put struct
> kvm_vcpu, and struct kvm? If we place them in x86.h, then kvm_main.c and
> other neutral files can't reach it.  If we put them in kvm.h, how to
> handle arch-specific fields in them ?
>   

Someone (I forget who) suggested using the same trick we use for vmx and 
svm.  We nest as follows:

struct vcpu_vmx {
   struct vcpu_x86 {
        struct kvm_vcpu {
             // common fields;
        } vcpu;
        // x86 specific fields;
   } x86;
   // vmx specific fields;
};

Allocation is done by arch specific code which allocates the outermost 
structure.  Common code sees only kvm_vcpu and its fields.  When it 
calls x86 arch hooks, they use the vcpu_x86() macro (which is a call to 
container_of()) to gain access to x86 specific fields.  When x86 code 
calls vmx specific code (using kvm_x86_ops), that uses vcpu_vmx() to 
gain access to the vmx specific fields.  Any similarity to a language 
derived from C, living or dead, is purely coincidental and unintended.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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/