From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Disscussion] Moving x86 code out of kvm.h Date: Thu, 15 Nov 2007 16:21:02 +0200 Message-ID: <473C55CE.9010000@qumranet.com> References: <1195115055.21627.17.camel@thinkpad> <42DFA526FC41B1429CE7279EF83C6BDC9A042D@pdsmsx415.ccr.corp.intel.com> <473C2509.5030308@qumranet.com> <42DFA526FC41B1429CE7279EF83C6BDC9A044F@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , kvm-ppc-devel , jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org To: "Zhang, Xiantao" Return-path: In-Reply-To: <42DFA526FC41B1429CE7279EF83C6BDC9A044F-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@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 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/