So Ali,
So far the reason why it woudn't boot is because it tlb.cc under case:
case ASI_SWVR_UDB_INTR_W:
postInterrupt(bits(data,5,0),0);
The bits(data, 5, 0) exceeds the NumInterruptTypes. And this is why when I
try to boot disk, I get ERROR: Last Trap: Fast Data Access MMU Miss. How
come you are reading bits 5 through 0 but only allowing < NumInterruptTypes?
So, what happens when I try to invoke boot disk at the "ok" prompt is it
complains about the unhandled interrupt and that's because of the problem I
described above.
On Sun, Mar 22, 2009 at 6:40 PM, Polina Dudnik <[email protected]> wrote:
> 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
