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
