On Mon, Aug 31, 2015 at 10:43:27AM +0300, Pavel Fedin wrote:
> 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?
>
I think it's worth moving the thing to device attributes, yes,
especially given that I never expect us to trap and emulate GICv3 system
register accesses from a guest in KVM. Is that correct?
However, if there's a strong argument that this is really CPU state and
not state associated with the GIC device, I'd be willing to reconsider.
-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
