On Wed, Apr 24, 2019 at 09:39:31AM +0000, Alex Bennée wrote:
>
> Dave Martin <Dave.Martin@xxxxxxx> writes:
>
> > Some optional features of the Arm architecture add new system
> > registers that are not present in the base architecture.
> >
> > Where these features are optional for the guest, the visibility of
> > these registers may need to depend on some runtime configuration,
> > such as a flag passed to KVM_ARM_VCPU_INIT.
>
> This combined with...
> > --- a/arch/arm64/kvm/sys_regs.h
> > +++ b/arch/arm64/kvm/sys_regs.h
> > @@ -64,8 +64,15 @@ struct sys_reg_desc {
> > const struct kvm_one_reg *reg, void __user *uaddr);
> > int (*set_user)(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
> > const struct kvm_one_reg *reg, void __user *uaddr);
> > +
> > + /* Return mask of REG_* runtime visibility overrides */
> > + unsigned int (*visibility)(const struct kvm_vcpu *vcpu,
> > + const struct sys_reg_desc *rd);
> > };
>
> this makes me wonder what sort of machines will see different register
> visibility depending on which vcpu you are running on?
Userspace can consciously set KVM_ARM_VCPU_SVE in vcpu_init.features[0]
for some vcpus and not for others.
For one thing, this is useful for testing how the guest responds to that
configuration.
This will for example allow Linux's handling of these weird
configurations to be tested directly rather than by hacking the
guest kernel to fake it up -- which is what I've had to do up to now.
> Reviewed-by: Alex Bennée <alex.bennee@xxxxxxxxxx>
Thanks!
(Note, Marc already picked the patches into kvmarm/next, so new tags
won't be applied. But the review is still appreciated, and if you spot
any issues I'd certainly like to know :)
Cheers
---Dave
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
