On Wed, Feb 27, 2019 at 02:17:06PM +0000, Julien Grall wrote: > Hi Dave, > > On 2/27/19 1:50 PM, Dave Martin wrote: > >On Wed, Feb 27, 2019 at 12:02:46PM +0000, Julien Grall wrote: > >>Hi Dave, > >> > >>On 2/26/19 5:01 PM, Dave Martin wrote: [...] > >>>The access_id_aa64zfr0_el1() should still be reachable, since we don't > >>>have REG_NO_GUEST for this. > >> > >>__access_id_reg is taking a boolean to tell whether the register is RAZ or > >>not. So you probably could re-use it passing !vcpu_has_sve(vcpu). > >> > >>It feels to me we would introduce a new restriction to tell whether the > >>register should be RAZ. Anyway, the new restriction is probably for a > >>follow-up patch. > > > >It's true that we should be able to handle these as regular ID regs in > >the get()/set() case, when SVE is enabled for the vcpu. I'll have a > >think about how to reduce the amount of special-case code here maybe > >we can indeed get of some of these accessors entitely now that access > >is rejected earlier, in a more generic way. > > > >The access() case for this register still has to be custom though; I > >don't see a trivial solution for that. > > I believe you can implement access_id_aa64zfr0_el1 in one line: > > return __access_id_reg(vcpu, p, r, !vcpu_has_sve(vcpu)); Could maybe do that -- I'll take a look. > Another possibility is to introduce REG_GUEST_RAZ and use the restrictions > callback to set it when the vCPU is not using SVE. This is possible, though I'm reluctant to introduce this for a one-off special case. Depending on how many registers follow the same pattern in the future, we could add it later on. Cheers ---Dave _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
