You make a good point, this does have some connection to the ARM system/ISA
objects and the configuration they manage. That had crossed my mind, but
since I came at this from a different direction I wasn't thinking of doing
something about that directly here. I definitely agree that how the ARM
system object and ISA object manage those settings is a bit unfortunate,
and I would really like to fix it somehow. I've thought about how to do
that on a few occasions, but I never really came up with anything that
seemed like it would be better than what's there now. You bringing it up
here has made me think about it again and I do have some possible ideas we
could explore, but (while it is related) I think this part is a bit more
basic and can be done separately without having to figure out the larger
issue. But to be clear, I definitely agree with you that that is an area we
need to improve for the reasons you mentioned.
Gabe
On Tue, Dec 15, 2020 at 2:14 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:
> 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
> *Sent:* 15 December 2020 05:53
> *To:* gem5 Developer List
> *Cc:* Gabe Black
> *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
