Best Regards. Yu > -----Original Message----- > From: Hollis Blanchard [mailto:hollisb@xxxxxxxxxx] > Sent: Thursday, August 28, 2008 4:19 AM > To: Liu Yu > Cc: kvm-ppc@xxxxxxxxxxxxxxx > Subject: RE: [PATCH 2/4] add e500 tlb implementation -- DCRs > > 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. :) Fixed. -- 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
