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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
