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:
> >On Tue, Feb 26, 2019 at 04:32:30PM +0000, Julien Grall wrote:
> >>On 18/02/2019 19:52, Dave Martin wrote:
> >>We seem to already have code for handling invariant registers as well as
> >>reading ID register. I guess the only reason you can't use them is because
> >>of the check the vcpu is using SVE.
> >>
> >>However, AFAICT the restrictions callback would prevent you to enter the
> >>{get, set}_id if the vCPU does not support SVE. So the check should not be
> >>reachable.
> >
> >Hmmm, those checks were inherited from before this refactoring.
> >
> >You're right: the checks are now done a common place, so the checks in
> >the actual accessors should be redundant.
> >
> >I could demote them to WARN(), but it may make sense simply to delete
> >them.
>
> I think removing the WARN() would be best as it would avoid to introduce
> most of the wrappers for the registers.
>
> >
> >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.
Cheers
---Dave
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
