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