Yep, got it. I may have been looking at the wrong invoke() before. Polina
On Sun, Mar 22, 2009 at 7:35 PM, Polina Dudnik <[email protected]> wrote: > I see. I will look at that because it's weird that when I boot the disk it > complains about unhandled MMU. > > > On Sun, Mar 22, 2009 at 7:21 PM, Ali Saidi <[email protected]> wrote: > >> >> >> It is changed when fault->invoke() is called. It then vectors to the >> OS which handles the fault and then calls retry(?) which rexecutes the >> instruction and away it goes. >> >> Ali >> >> On Mar 22, 2009, at 6:11 PM, Polina Dudnik wrote: >> >> > 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 <[email protected]> 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 <[email protected]> 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 >> > <[email protected]> >> > > > 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 <[email protected]>: >> > > > > 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 <[email protected] >> > > >> > > > 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 >> > > > <[email protected]> wrote: >> > > > >>> >> > > > >>> >> > > > >>> On Fri, Mar 20, 2009 at 1:11 PM, Ali Saidi <[email protected]> >> > > > 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 <[email protected] >> > > >> > > > 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 >> > > > >>>> > > [email protected] >> > > > >>>> > > http://m5sim.org/mailman/listinfo/m5-dev >> > > > >>>> > >> > > > >>>> > _______________________________________________ >> > > > >>>> > m5-dev mailing list >> > > > >>>> > [email protected] >> > > > >>>> > http://m5sim.org/mailman/listinfo/m5-dev >> > > > >>>> > >> > > > >>>> > _______________________________________________ >> > > > >>>> > m5-dev mailing list >> > > > >>>> > [email protected] >> > > > >>>> > http://m5sim.org/mailman/listinfo/m5-dev >> > > > >>>> >> > > > >>>> _______________________________________________ >> > > > >>>> m5-dev mailing list >> > > > >>>> [email protected] >> > > > >>>> http://m5sim.org/mailman/listinfo/m5-dev >> > > > >>> >> > > > >> >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > m5-dev mailing list >> > > > > [email protected] >> > > > > http://m5sim.org/mailman/listinfo/m5-dev >> > > > > >> > > > > >> > > > _______________________________________________ >> > > > m5-dev mailing list >> > > > [email protected] >> > > > http://m5sim.org/mailman/listinfo/m5-dev >> > > > >> > > > _______________________________________________ >> > > > m5-dev mailing list >> > > > [email protected] >> > > > http://m5sim.org/mailman/listinfo/m5-dev >> > > >> > > _______________________________________________ >> > > m5-dev mailing list >> > > [email protected] >> > > http://m5sim.org/mailman/listinfo/m5-dev >> > > >> > > _______________________________________________ >> > > m5-dev mailing list >> > > [email protected] >> > > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > _______________________________________________ >> > m5-dev mailing list >> > [email protected] >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > _______________________________________________ >> > m5-dev mailing list >> > [email protected] >> > http://m5sim.org/mailman/listinfo/m5-dev >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
