Hi Gabe,
Let me first say that I like what you are trying to do.
Are you thinking about changing the querying interface only, or are you
thinking about restructuring the back-end as well? Like where ISA specific
parameters are actually stored? For example in Arm we have system level
properties stored in the ArmSystem and cached in the ISA class.
(So if you just want to change the “front-end”, it would be
tc->checkFeature->isa->feature or
tc->checkFeature->isa->system->feature)
I’ve always felt the need of sorting out the ArmSystem mess, which is providing
capabilities for *FS oly*
So we usually configure system level parameters for FS and we hardcode some of
those in SE mode (ArmSystem is not instantiated in SE).
I believe a reasonable approach would be to define a global System Level
parameters object which will be used for both SE and FS, replacing what we are
doing with the ArmSystem.
Not trying to push any work on you, simply sharing my view in case there was an
overlap with your plan
Kind Regards
Giacomo
From: Gabe Black via gem5-dev <gem5-dev@gem5.org>
Sent: 15 December 2020 05:53
To: gem5 Developer List <gem5-dev@gem5.org>
Cc: Gabe Black <gabe.bl...@gmail.com>
Subject: [gem5-dev] CPU/thread context capabilitiy/feature bits
Hi folks. There have been a number of situations I've run into where different
CPU models support different features. Some of these are generic:
"Hardware" breakpoints - not supported in KVM
GDB support in general?
Different gem5 op mechanisms - instruction based, address based
SMT
checkpointing
And some are architecture specific:
ARM
Semihosting based gem5 ops
GIC version
x86 -
Syscall/sysret vs. sysenter/sysexit in compatibility mode
major vendor differences like SVM vs VMX
Level of support for SIMD instruction set
When running a KVM CPU, these things can even depend on what the host is, ie
what support the host CPU has which can be exposed to the simulation.
Rather than try to just pick something that will break in the least painful
way, or try to check for particular models to try to infer what's supported, or
to have to manually configure things to avoid missing features, it would be
really helpful, I think, for the models to be able to just declare what they
support.
I haven't thought about this super deeply yet, but my thought so far is to have
a new ThreadContext function, something like FeatureVal
checkFeature(FeatureNum) where FeatureVal is an int64_t, and FeatureNum is a
uint64_t or possibly an enum. If a feature isn't recognized, the return value
should be something inert like 0 or -1, and if it is then the meaning of the
value depends on the definition of the feature. The FeatureNum value would have
two (or more?) classes, one which would be generic (MSB is 0?) and one which
would be ISA specific (MSB is 1?). The CPU would directly answer generic
requests because it would know the answer, and would dispatch non-generic
requests to the ISA object.
Alternatively they could be called Capabilities instead of Features?
Thoughts?
Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
