On Wed, 2008-08-27 at 10:50 +0800, Liu Yu wrote: > > -----Original Message----- > > From: kvm-ppc-owner@xxxxxxxxxxxxxxx > > [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On Behalf Of Hollis Blanchard > > Sent: Tuesday, August 26, 2008 11:51 PM > > To: Liu Yu > > Cc: kvm-ppc@xxxxxxxxxxxxxxx > > Subject: RE: [PATCH 2/4] add e500 tlb implementation -- DCRs > > > > On Fri, 2008-08-22 at 17:10 +0800, Liu Yu wrote: > > > > > +#define mtdcr(rn, val) > > > > > > > > > > > > > define mtdcr to what ? > > > > > > To null. I think it return void. > > > E500 doesn't support dcr. > > > Finally there is a place could be simpler than 44x. :-) > > > > It would be better to ifdef or abstract the DCR code in emulate.c so > > that it's not compiled on e500. The same goes for emulation of > > e500-specific instructions (probably just SPRs like EPR) on 440 -- I > > think we should split kvmppc_emulate_instruction() somehow. > > > > There's an open question about being able to run e.g. a 440 > > guest on an > > e500 host, but since nobody I've talked to seems interested in that I > > think it's OK not to allow that for now. (However, I do want to make > > sure our design/layering allows for that at some point in the > > future, if > > it becomes interesting.) > > > > In fact, this is one problem I want to discuss on list. > Do we have to split all core-specific things? Such as SPRs as you said, > additional exceptions, core-specific instructions etc. > Do you mean it is helpful to find out potential errors or to debug sth.? > > Except that I think It's not a big deal if they don't conflict with the > normal behavior of KVM. > For example, although 44x and E500 have specific SPR, but they are > defined different numbers. > Maybe it make guest somewhat confused, > but we could no more need ifdef which may make code more complicated and > harder to read. > And kernel has some instructions emulation as well. OK, I think I agree that we can just leave the code for both cores active but unused. That includes adding fields to kvm_vcpu_arch. (There is probably some small performance penalty for that, but I don't think we're even close to that mattering.) On the other hand, the "mtdcr" hack offends me, so I think that deserves an ifdef instead of stubbing it out. :) -- 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
