> -----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. Anyway, both seem OK to me. -- 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
