Ok, sorry for the long delay. I've had family visiting, and a cold, and
house issues, and been busy with work, and getting ready for a trip, so
I've been stretched pretty thin, but I should have a little more time now.
Right now, there's a doCpuid function which takes in a ThreadContext
pointer, some values identifying what CPUID function to do, and an object
to stuff results into.
In the existing implementation the ThreadContext pointer isn't being used,
but I imagine (since I don't remember any more) that that was for digging
up values to return for, for instance, cache sizes, etc. That's probably
not a great way to extract that info since it would mean having to string
pointers around which breaks modularity a lot (the TC interface effectively
includes all the interfaces you can grab pointers to through it, so it's
effectively arbitrarily large). A better way to do something along those
lines would be to traverse the python SimObjects which have nice, easy to
get at properties in well defined places which generally represent the
sorts of values CPUID would return (cache sizes, etc.).
What I would suggest then is to make a new python version of doCpuid, maybe
called x86_doCpuid since our python module hierarchy is a bit flat, which
would be exported to C++ and called instead of the C++ version. The C++
CpuidResult class would be exposed to python through pybind, and passed to
the python function just like the C++ version. The indexing parameters
would also work the same as they do now.
The ThreadContext pointer would need to be replaced with some other sort of
anchoring reference to something in the python hierarchy, maybe with a
reference to the CPU and a thread number or something like that. That would
give the CPUID servicing code a way to crawl around the hierarchy starting
in the right place so it knows *who's* cache it's supposed to describe.
Then after that, I think we could have a simple dict which maps from a
CPUID function/index pair to a function which would handle that pair. The
python CPUs (for instance) would have a non-gem5-parameter member variable
(that may be annoying to get to work) which holds that dictionary.
def x86_doCpuid(cpu, function, index, result):
key = (function, index)
if not key in cpu.cpuid_handlers:
return False
handler = cpu.cpuid_handlers[(function, index)]
return handler(cpu, function, index, result)
cpu = SimpleAtomicCpu()
cpu.cpuid_handlers[(0x80000000, 0x0)] = VendorAndLargestExtFunc("M5
Simulator", 8)
Looking at that, I'm thinking that we might want something mildly smarter
than a generic dict to do the matching if, for instance, the index value
doesn't matter except under certain circumstances, and so a "None" in that
part of the pair would work like a wildcard and match with any actual value.
Anyway, that's sort of my thoughts more or less off the cuff. Does that
make any sense?
Gabe
On Tue, May 15, 2018 at 12:58 AM, Gabe Black <[email protected]> wrote:
> 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
