Re: [PATCH] Split kvm_vcpu to support new archs.

[Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

On Sun, 2007-10-21 at 08:40 +0200, Avi Kivity wrote:
> 
> The usage of the macro is only for an intermediate stage, so this
> patch shows the changes in the data structures, while the next one
> will be littered with code changes due to the changes in the way
> fields are addressed.

OK.

What is the plan here Xiantao? If I want to begin PPC integration,
should I submit some patches too (hopefully in areas where we will not
conflict)? Or should I just review your submissions and hold off on PPC
code changes until the dust settles?

> I was initially in favor of doing
> 
>     struct kvm_vcpu {
>         struct kvm_vcpu_common common;
>         ...
>     };
> 
> in order to avoid the majority of fields requiring an 'arch.' prefix 
> (most fields are arch dependent, very few are common), but using 
> container_of() as someone suggested seems to be a better idea. 

Note: container_of() enables the above layout, and I agree with that
approach. To avoid misunderstandings, this is what we're talking about:
        
        kvm_common_foo(struct kvm_vcpu_common *vcpu)
        {
        	kvm_arch_foo(vcpu);
        }
        
        kvm_common_bar(struct kvm_vcpu_common *vcpu)
        {
        	...
        }
        
        ----------
        
        struct kvm_vcpu_ppc440 {
        	struct kvm_vcpu_common common;
        	u32 gpr[32];
        };
        
        #define to_ppc440(v) container_of(...)
        
        kvm_arch_foo(struct kvm_vcpu_common *vcpu)
        {
        	struct kvm_vcpu_ppc440 *ppc440 = to_ppc440(vcpu);
        
        	ppc440->gpr[3] = 0;
        
        	kvm_common_bar(ppc440->common);
        }
        
I've chosen specific PPC names since I expect to support more than one
PowerPC processor type simultaneously, e.g. "modprobe kvm-powerpc-440
kvm-powerpc-e500". (This will require some additional "kvm_ppc_ops"
support not shown here.)

Personally I think "common" is too much typing, but I've left the name
as you suggested for now. :)

-- 
Hollis Blanchard
IBM Linux Technology Center


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