> -----Original Message----- > From: kvm-ppc-owner@xxxxxxxxxxxxxxx > [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On Behalf Of Hollis Blanchard > Sent: Thursday, December 18, 2008 1:03 AM > To: Liu Yu-B13201 > Cc: kvm-ppc@xxxxxxxxxxxxxxx > Subject: RE: [PATCH 07/11] E500 TLB emulation > > On Wed, 2008-12-17 at 11:07 +0800, Liu Yu wrote: > > > -----Original Message----- > > > From: kvm-ppc-owner@xxxxxxxxxxxxxxx > > > [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On Behalf Of > Hollis Blanchard > > > Sent: Tuesday, December 16, 2008 11:44 PM > > > To: Liu Yu-B13201 > > > Cc: kvm-ppc@xxxxxxxxxxxxxxx > > > Subject: RE: [PATCH 07/11] E500 TLB emulation > > > > > > On Tue, 2008-12-16 at 18:08 +0800, Liu Yu wrote: > > > > > > > > > To fix this, instead of doing error-checking in all these > > > > > sites, I would > > > > > just mask with 1 instead of 3. > > > > > > > > > > > > > If the guest instruction appoint MAS0[TLBSEL] = 2 or 3, > > > > I think the best way is to ignore it. > > > > > > Masking with 1 instead of 3 will ignore it. Or do you > mean completely > > > ignore the instruction? The mask is and simpler and > faster, and also > > > perfectly legal (it was a software error to begin with). > > > > > > Actually, my e500 user manual (covering v1 and v2) says the > > > TLBSEL field > > > is only 1 bit wide, with reserved bits on either side. So > > > masking with 1 > > > is clearly the right solution. > > > > > > > I found the problem. > > Old manual explain the tlbivax EA format that bit 60 is > used for tlbsel. > > Howerver the newest verstion tells that bit 59~60 of > tlbivax EA are used > > for tlbsel. > > Correspondingly, the MAS0 use 34~35 bits for tlbsel now. > > > > > http://www.freescale.com/files/32bit/doc/ref_manual/EREFRM.pdf > ?WT_TYPE=R > > > eference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_A > SSET=Docum > > entation > > This document is strange, because it seems to be trying to describe > multiple Freescale cores in conjunction with the full architecture. I > have to believe that the core's user manual is more accurate, since it > provides information about divergences from the architecture. The e500 > UM says tlbsel is 1 bit, so that's what I believe. > > > I think I should check the case that tlbsel is not valid in > the code. > > And do what if the check fails? The document you listed above says "If > the specified entry does not exist, the results are > undefined" for both > tlbwe and tlbre, which means you get to do whatever you want. > > You already open-code TLBSEL extraction in a number of places: > get_tlb_tlbsel() uses MAS0, tlbivax uses the effective address, and > tlbsx uses MAS4. It makes me nervous because the more places > you do it, > the more likely it is you'll miss a check somewhere. > > Look at it this way: no good *at* *all* can come from having (tlbsel & > 0x2) == 1. There is absolutely no reason that should ever happen. So > don't allow it to happen, and do it automatically so there's never a > risk of forgetting to check for that condition. Hmm. I think you're right. This is a simplest way to keep code safe. Fixed all. -- 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
