Hi Gavin, On Tue, Apr 14, 2020 at 03:39:56PM +1000, Gavin Shan wrote: > On 4/10/20 10:52 PM, Marc Zyngier wrote: > > On 2020-04-10 09:58, Gavin Shan wrote: > > > In order to fulfil the control flow and convey signals between host > > > and guest. A IMPDEF system register (SYS_ASYNC_PF_EL1) is introduced. > > > The register accepts control block's physical address, plus requested > > > features. Also, the signal is sent using data abort with the specific > > > IMPDEF Data Fault Status Code (DFSC). The specific signal is stored > > > in the control block by host, to be consumed by guest. > > - We don't add IMPDEF sysregs, period. That's reserved for the HW. If > > you want to trap, there's the HVC instruction to that effect. > I really don't understand how IMPDEF sysreg is used by hardware vendors. > Do we have an existing functionality, which depends on IMPDEF sysreg? > I was thinking the IMPDEF sysreg can be used by software either, but > it seems I'm wrong. The key is in the name: an IMPLEMENTATION DEFINED register is defined by the implementation (i.e. the specific CPU microarchitecture), so it's wrong for software to come up with an arbitrary semantic as this will differ from the implementation's defined semantic for the register. Typically, IMP DEF resgisters are used for things that firmware needs to do (e.g. enter/exit coherency), or for bringup-time debug (e.g. poking into TLB/cache internals), and are not usually intended for general purpose software. Linux generally avoids the use of IMP DEF registers, but does so in some cases (e.g. for PMUs) after FW explicitly describes that those are safe to access. Thanks, Mark. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
