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

Jerone Young
2007-10-25T02:56:54Z

This may be helpful to everyone if Hollis's explanation of container_of
didn't help:

Lookup up "container_of" or look at the secion named "Lists"
at this link:
http://www.win.tue.nl/~aeb/linux/lk/lk-2.html

It also contains the macro used in the kernel.

On Mon, 2007-10-22 at 14:18 -0500, Hollis Blanchard wrote:
> 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. :)