I'm hoping to have another opportunity to think about this more and flesh out my suggestion, but I've been pretty busy recently and haven't had a chance. I do intend to though, once I get a chance.
Gabe On Fri, May 11, 2018 at 2:08 PM, Gutierrez, Anthony < [email protected]> wrote: > "This might be a place where it would make sense to somehow bridge between > python and c++ and let the config specialize some sort of function or dict > or tree of dicts or whatever which decode what CPUID function is being > requested." > > Can you expand on the details of this statement a bit more? > > My initial thoughts were that it would not be so hard to specialize the > CPUID function because there are only 2 flavors. I was thinking we could > move the functionality provided by doCpuid() into its own class and make it > a Param of the X86 ISA sim object. Or, simply give the ISA object a > "flavor" param that will execute the correct CPU ID functionality based on > the flavor of the ISA. Although, if I understand what you're describing at > a high-level, it would be more automated/integrated with Scons, which may > be good. > > The bigger issue to me is how to properly serve some of the CPUID > functions, like the functions that describe the cache hierarchy. It didn't > seem to be that easy to access all of that info from doCpuid() currently, > although much of it may be, in one way or another, accessible through the > thread context. > > -----Original Message----- > From: gem5-dev [mailto:[email protected]] On Behalf Of Gabe Black > Sent: Thursday, May 03, 2018 6:26 PM > To: gem5 Developer List <[email protected]> > Subject: Re: [gem5-dev] Question about vendor-specific x86 CPUID functions > > Yeah, that's a good question, and I don't have a specific plan for how to > handle it. Since gem5 nominally simulates some sort of abstract x86 CPU > which isn't really Intel or AMD or anybody (although probably most like AMD > because those are the manuals I used), it sits in a weird area where code > written for the real world probably doesn't know quite what to do with it. > > This might be a place where it would make sense to somehow bridge between > python and c++ and let the config specialize some sort of function or dict > or tree of dicts or whatever which decode what CPUID function is being > requested. We should consider how much interaction there would need to be > between a system like that and the c++ side of the hardware, or if, for > instance, it could somehow crawl the SimObject hierarchy in python to find > out what values to return for, say, cache sizes, etc. I've been playing > around with the interface between c++ and python, and while it's still a > bit mysterious still, it's actually pretty powerful and fairly > straightforward to use. > > With that sort of setup, if you wanted to make it look like a particular > model of AMD cpu or Intel CPU or your own magic CPU, or add in some > additional CPUID field for some reason, all of that would be relatively > accessible and easier to customize on a per CPU basis. > > What do you think? > > Gabe > > On Thu, May 3, 2018 at 2:55 PM, Gutierrez, Anthony < > [email protected]> wrote: > > > This question is mostly for Gabe. In the ROCm runtime we see some > > inline asm for specific CPUID functions. They first use CPUID to > > determine the name string for the processor, and when it seems the "M5 > > Simulator" as the vendor it defaults to Intel and sends along the > > CPUID request with the Intel-specific ID for cache config descriptors. > > The ID used by Intel is different than is used by AMD for the same > function. > > I am just wondering what your thoughts are about implementing these > > functions. Do we implement the CPUID functions for only one vendor? Is > > there a way to make it configurable? > > > > Currently I am not bothering to implement it, I am simply returning > > {0x0, 0x0, 0x0, 0x0} and issuing a warn (in cupid.cc), but I still > > need to add the particular ID to the StandardCpuidFunction enums in > > order for it to be considered in the switch statement. > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
