Ali, I traced the FastDataAccessMMUMiss and it seems that the fault triggers advancePC function, which calls predecode.reset() and that's about it. predecode.reset() doesn't seem to be doing anything either. Shouldn't the PC be changed to the start of the handling routine? Or am I missing something? Where is the FastDataAccessMMUMiss actually handled?
Polina On Sun, Mar 22, 2009 at 5:39 PM, Ali Saidi <sa...@umich.edu> wrote: > number of CPUs as I've defined them. If you wanted 8 contexts you > would pass -n 8 > > Ali > > On Mar 22, 2009, at 5:09 PM, Polina Dudnik wrote: > > > So, when I pass -n 2, shouldn't there be 8 thread contexts: 4 for > > each processor? Or is -n 2 is the number of CPUs as you define them? > > > > On Sun, Mar 22, 2009 at 5:02 PM, Ali Saidi <sa...@umich.edu> wrote: > > The latter. The OS/hypervisor may believe that there are multiple > > threads on a CPU, but in reality there are actually multiple CPUs. All > > the code I wrote for threads/cpus as far as the OS/hypervisor layer is > > concerned assumed this (e.g. take the thread context ID % 4 to get the > > CPU/thread id. > > > > Ali > > > > On Mar 22, 2009, at 2:47 PM, Polina Dudnik wrote: > > > > > So, you just don't allow multiple threads on a cpu or you attempt to > > > flatten out multiple threads into multiple cpus? > > > > > > On Fri, Mar 20, 2009 at 5:31 PM, Steve Reinhardt <ste...@gmail.com> > > > wrote: > > > By default, we do not simulate multithreading. The SimpleCPU models > > > are single-threaded. The O3 model does have SMT capability, but > > it's > > > not enabled by default, and I'm not sure it's ever been used in FS > > > mode so there may well be bugs there. > > > > > > Steve > > > > > > 2009/3/20 Polina Dudnik <pdud...@gmail.com>: > > > > Ali, > > > > > > > > Just to be clear: do or you do not simulate multithreading? > > > > > > > > There are two options that I can imagine: > > > > > > > > 1. When I pass -n 2 there are two multithreaded processors, each > > > of which > > > > has four thread contexts. In that case, seeing the ipi for > > > "cpu_id" 4 is > > > > completely right, because the ipi's come in for the threads, and > > > not cpu's. > > > > So, the simulator should not be getting confused about the ipi for > > > 4. > > > > > > > > > > > > OR > > > > > > > > 2. You simulate each thread context as a processor. In that case, > > > when I > > > > pass -n 2, there really should be 8 processors. In that case, > > > again ipi for > > > > 4 is entirely right. > > > > > > > > Which one is it? > > > > > > > > Thanks, > > > > > > > > Polina > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 20, 2009 at 2:54 PM, Polina Dudnik <pdud...@gmail.com> > > > wrote: > > > >> > > > >> Regarding running one processor with two threads, now that I > > > think about > > > >> it, OpenSparc definitely assigns thread numbers and not processor > > > numbers in > > > >> hardware description file. Niagara does not have 32 processors, > > > but can have > > > >> 32 threads. So, by assigning thread numbers to be 0 and 4, it > > > ensures that > > > >> the threads are run on different processors. This is why the > > > number is 4. It > > > >> is the thread number. > > > >> > > > >> So I think those really are the cpu numbers as seen by the OS, > > > and they > > > >> have to be swizzled. > > > >> > > > >> Can you please tell me where you got the format for the ipi > > > message. So, > > > >> to be more clear in iob.cc: > > > >> > > > >> > > > >> data = pkt->get<uint64_t>(); > > > >> type = (Type)bits(data,17,16); > > > >> cpu_id = bits(data, 12,8); > > > >> vector = bits(data,5,0); > > > >> generateIpi(type,cpu_id, vector); > > > >> > > > >> > > > >> How do you know that cpu_id is at bits 5 through 0? I keep > > > looking through > > > >> OpenSparc documentation but can't find it. > > > >> > > > >> > > > >> Thanks. > > > >> > > > >> Polina > > > >> > > > >> > > > >> On Fri, Mar 20, 2009 at 1:26 PM, Polina Dudnik > > > <pdud...@gmail.com> wrote: > > > >>> > > > >>> > > > >>> On Fri, Mar 20, 2009 at 1:11 PM, Ali Saidi <sa...@umich.edu> > > > wrote: > > > >>>> > > > >>>> Yea, that makes sense. You should probably look at the TLBs > > > (that is > > > >>>> where a lot of the miscellaneous system registers live). The > > > confusion > > > >>>> probably comes from reading one of those and the ids not being > > > >>>> swizzeled, or perhaps there is an interrupt message with a CPU > > > id or > > > >>>> something as well. > > > >>> > > > >>> > > > >>> Right, that's what I was thinking. I will look at the TLB's and > > > the > > > >>> interrupt. Perhaps you can help me with a more specific > > > question: when I > > > >>> post an interrupt, I basically write a bit in the interrupt > > > array. How does > > > >>> the hypervisor find out about it? Who reads the interrupt array? > > > >>> > > > >>>> > > > >>>> > > > >>>> I guess your attempts at convincing the hypervisor that the > > > next cpu > > > >>>> was #1 failed? > > > >>> > > > >>> It is not even that. According to David Wood, it might not be > > > the best > > > >>> idea to change cpu numbers because there are a lot of things > > > that determine > > > >>> the cpu numbers. So, I think the reason that changing the > > hardware > > > >>> description files did not have any effect is because the > > > description files > > > >>> are fitted to the hypervisor and not the other way around. I am > > > right now > > > >>> trying to find where the hardware description binary is used if > > > ever. > > > >>> > > > >>> > > > >>>> > > > >>>> What about calling the next CPU thread 1 (e.g. make a > > > >>>> system with 2 threads and 1 core)? > > > >>> > > > >>> Yes, I remember I was supposed to do that. Sorry for the delay, > > > I will > > > >>> certainly try that. Currently I am trying to run 32 processors > > > because at > > > >>> least they are ordered and shouldn't require swizzling, so we'll > > > see what > > > >>> happens. > > > >>> > > > >>> > > > >>>> > > > >>>> Ali > > > >>>> > > > >>>> > > > >>>> > > > >>>> On Mar 20, 2009, at 12:52 PM, Polina Dudnik wrote: > > > >>>> > > > >>>> > Right, I wasn't going to modify the hypervisor. But swizzling > > > the > > > >>>> > numbers clearly affects the hypervisor because when > > > hypervisor sends > > > >>>> > messages, the processor number is swizzled from 4 to 1. So, > > > >>>> > initially the hypervisor thinks that there are cpu #0 and #4, > > > but > > > >>>> > then it probably receives some messages or whatever, which > > > have cpu > > > >>>> > #1. So, I think the reason that the hypervisor reports that > > > cpu1 > > > >>>> > failed to start is due to the confusion over the cpu numbers. > > > Does > > > >>>> > this make sense? > > > >>>> > > > > >>>> > So, if m5 shall use cou #0 and #1 internally, it should make > > > sure > > > >>>> > that all the external messages are suited for the binaries > > form > > > >>>> > OpenSparc. > > > >>>> > > > > >>>> > Polin > > > >>>> > > > > >>>> > On Fri, Mar 20, 2009 at 12:02 PM, Ali Saidi <sa...@umich.edu> > > > wrote: > > > >>>> > The changes should only affect the portions of the system > > > that the > > > >>>> > hypervisor is calling. There shouldn't be any changes > > > required within > > > >>>> > the hypervisor code. > > > >>>> > > > > >>>> > Ali > > > >>>> > > > > >>>> > On Mar 19, 2009, at 1:22 PM, Polina Dudnik wrote: > > > >>>> > > > > >>>> > > Hi, > > > >>>> > > > > > >>>> > > So, to make sparc_fs work Ali and later I swizzled the > > > processor > > > >>>> > > numbers from 4 to 1 because m5 expects 1 and gets 4. In > > > order to > > > >>>> > > make this hack work, we also need to swizzle the numbers > > > back before > > > >>>> > > calling the hypervisor. So, the processor numbers going > > > into the > > > >>>> > > hypervisor should be swizzled back. So, in effect there > > > should be a > > > >>>> > > map which enables translation both ways. Does anyone know > > > where I > > > >>>> > > can start looking for calls to the hypervisor? Thank you. > > > >>>> > > > > > >>>> > > Polina > > > >>>> > > > > > >>>> > > > > > >>>> > > _______________________________________________ > > > >>>> > > m5-dev mailing list > > > >>>> > > m5-dev@m5sim.org > > > >>>> > > http://m5sim.org/mailman/listinfo/m5-dev > > > >>>> > > > > >>>> > _______________________________________________ > > > >>>> > m5-dev mailing list > > > >>>> > m5-dev@m5sim.org > > > >>>> > http://m5sim.org/mailman/listinfo/m5-dev > > > >>>> > > > > >>>> > _______________________________________________ > > > >>>> > m5-dev mailing list > > > >>>> > m5-dev@m5sim.org > > > >>>> > http://m5sim.org/mailman/listinfo/m5-dev > > > >>>> > > > >>>> _______________________________________________ > > > >>>> m5-dev mailing list > > > >>>> m5-dev@m5sim.org > > > >>>> http://m5sim.org/mailman/listinfo/m5-dev > > > >>> > > > >> > > > > > > > > > > > > _______________________________________________ > > > > m5-dev mailing list > > > > m5-dev@m5sim.org > > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > > > > > _______________________________________________ > > > m5-dev mailing list > > > m5-dev@m5sim.org > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > _______________________________________________ > > > m5-dev mailing list > > > m5-dev@m5sim.org > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
