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
