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

Hollis Blanchard
2007-10-22T19:18:01Z

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