On Thu, 2008-12-11 at 15:30 -0600, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > +int kvm_arch_get_registers(CPUState *env)
> > +{
> > + struct kvm_regs regs;
> > + uint32_t i, ret;
> > +
> > + ret = kvm_vcpu_ioctl(env, KVM_GET_REGS, ®s);
> > + if (ret < 0)
> > + return ret;
> > +
> > + env->ctr = regs.ctr;
> > + env->lr = regs.lr;
> > + env->xer = regs.xer;
> > + env->msr = regs.msr;
> > + /* calculate hflags based on the current msr using the ppc qemu helper */
> > + hreg_compute_hflags(env);
> >
>
> Do you need this? Practically speaking, I don't even think we need to
> maintain them on x86 anymore.
Ah, it seems you're right. That's good.
> > diff --git a/target-ppc/kvm_ppc.c b/target-ppc/kvm_ppc.c
> > new file mode 100644
> > index 0000000..b2b56df
> > --- /dev/null
> > +++ b/target-ppc/kvm_ppc.c
> >
>
> Hence my confusion. These are just kvm related helper?
>
> I don't know that kvm_ppc.c is a very information name for this sort of
> stuff. Since this is really host specific, not target specific, why not
> move it out of target-ppc.
I could combine kvm_ppc.c into target-ppc/kvm.c. However, they're really
two different things, and I thought it would cause the least confusion
if they were logically separate. Most of it is hooks required by common
code, and then some of it isn't. (I'm thinking about e.g. IA64 doing a
copy/paste, and then wondering which functions they actually need to
implement.) Regardless, I will still need a kvm_ppc.h, so kvm_ppc.c
seemed like a good place to match.
I don't see that you can call any KVM code either host- or
target-specific, since by definition they are the same.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
