I see. I am running one processor with two threads right now. When I pass it -n 2, it doesn't like that and complains about the bad address. I looked at why the address is bad and it is because the register value is zero. So, something is going wrong. With -n 1 everything is fine so far.
Ali, I actually looked more into the error print-outs I am getting. First, I realized that cpu1 is the right thing to be printed out because it is OS printing out this message and virtual ID should be 1. And here's something I found online regarding the specific error: Forced Stop of a Logical Domain Can Result in a Panic on the Next Boot (Bug ID 6543418) When using the force (-f) option to the ldm stop-domain command, the domain could panic with one of the following two signatures the next time the domain is started: - panic[cpu0]/thread=180e000: cpu1 failed to start (2) - panic[cpu0]/thread=180e000: bad kernel MMU miss at TL 2 *Recovery*: The condition that causes the panic is not persistent. After the panic, the logical domain can be restarted normally. *Workaround*: Whenever possible, do not use the force (-f) option to the ldm stop-domain command. If it is absolutely necessary to use the force option, unbind the logical domain before restarting it. So, I am guessing this is why immediately after panicking it attempts to reboot but fails. It failes because the prom fails to reboot and I think this might be because the FastDataAssessMMU trap is unhandled or something like that. And that might have to do with processor numbers. Do logical domains come into play anywhere in m5? I guess I am not sure if it is ldm stop-domain with -f that causes the panic call. So, I am trying to confirm that and also tracing the MMU fault handling. 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
