Hello!
> > I had imagined we would encode the GICv3 register accesses through the
> > device API and not through the system register API, since I'm not crazy
> > about polluting the general system register handling logic with GIC
> > registers solely for the purposes of migration.
>
> There's an interesting design question lurking under this
> about the extent to which you expose the h/w design split
> between the CPU interface and the GIC proper as part of the
> KVM APIs.
I could split up handling logic from access logic. So that in sys_regs.c we
would have something like:
static bool access_gic_ctlr(struct kvm_vcpu *vcpu,
const struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
return vgicv3_access_ctlr(vcpu, vcpu_reg(vcpu, p->Rt), p->is_write);
}
And in vgic-v3-emul.c we would have the handler itself with the prototype:
bool vgicv3_access_ctlr(struct kvm_vcpu *vcpu, u64 *val, bool write);
Would this be OK?
In my personal opinion system register access API fits perfectly well for this
task, because after all these are system registers. And implementing this as
device attribute would, i guess, give no difference from code's point of view.
We would have to encode system register numbers into attribute, then perform
table lookup, actually duplicating our system register access code. Does it
worth that?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
