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 <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
