"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
