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:
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.
I believe you can implement access_id_aa64zfr0_el1 in one line:
return __access_id_reg(vcpu, p, r, !vcpu_has_sve(vcpu));
Another possibility is to introduce REG_GUEST_RAZ and use the
restrictions callback to set it when the vCPU is not using SVE.
Cheers,
--
Julien Grall
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
