From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
Subject: Re: [PATCH] Split kvm_vcpu to support new archs.
Date: Thu, 18 Oct 2007 16:31:01 -0500
Message-ID: <4717D095.40708@codemonkey.ws>
References: <42DFA526FC41B1429CE7279EF83C6BDC809A6A@pdsmsx415.ccr.corp.intel.com>	
	<1192737702.21205.17.camel@basalt> <4717CA4B.7040307@codemonkey.ws>
	<1192742084.21205.22.camel@basalt>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	kvm-ppc-devel <kvm-ppc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
	"Zhang, Xiantao" <xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Return-path: <kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
In-Reply-To: <1192742084.21205.22.camel@basalt>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
List-Help: <mailto:kvm-devel-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org?subject=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

Hollis Blanchard wrote:
> On Thu, 2007-10-18 at 16:04 -0500, Anthony Liguori wrote:
>   
>> Hollis Blanchard wrote:
>>     
>>> What is the problem with
>>> embedding an architecture-specific sub-structure, i.e.
>>>         struct kvm_vcpu {
>>>                 ...
>>>                 struct arch_kvm_vcpu arch_vcpu;
>>>         };
>>>   
>>>       
>> I think you want the opposite direction of nesting. 
>>     
> ...
>   
>> We should move to:
>>
>> struct kvm_vcpu {
>>  /* stuff common to x86/ppc/ia64 */
>> };
>>
>> struct vcpu_x86 {
>>   struct kvm_vcpu vcpu;
>>   /* stuff common to vt/svm */
>> }
>>
>> struct vcpu_svm {
>>   struct vcpu_x86 vcpu;
>>   /* svm specific stuff  */
>> };
>>     
>
> Why?
>   

It provides better encapsulation.  If you have a kvm_vcpu, unless you do 
container_of(), you can't access the arch_vcpu.  It helps make sure that 
architecture common code remains common.

It also leaves open the possibility of supporting multiple architectures 
at the same time.  I don't know why you would want to do that :-)

Regards,

Anthony Liguori


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