Hello!
> > + reg = c->pendbaser & (GICR_PENDBASER_OUTER_CACHEABILITY_MASK |
> > + GICR_PENDBASER_ADDR_MASK |
> > + GICR_PENDBASER_SHAREABILITY_MASK |
> > + GICR_PENDBASER_CACHEABILITY_MASK);
> > + if (!c->redist_ctlr & GICR_CTLR_ENABLE_LPIS) {
> > + reg |= GICR_PENDBASER_PTZ;
> > + }
>
> Why does the state of the pendbaser register depend on state in the
> redist_ctlr ?
PTZ bit is write-only, we cannot read it back. And spec says that setting PTZ
is adviced while LPIs are not enabled, because it shortens down the time of GIC
initialization. So, i had to implement this small heuristics here. Is this
approach OK?
> Worth a comment, whatever the answer is.
I will.
> > + kvm_gicr_access(s, GICR_PENDBASER, ncpu, ®, false);
> > + c->pendbaser = reg & (GICR_PENDBASER_OUTER_CACHEABILITY_MASK |
> > + GICR_PENDBASER_ADDR_MASK |
> > + GICR_PENDBASER_SHAREABILITY_MASK |
> > + GICR_PENDBASER_CACHEABILITY_MASK);
>
> Why do we need to mask these values?
I decided to do this at least for the case of KVM->TCG migration (as far as i
understand, such things are possible). In this case i think we should not
pollute our state with read-only bits, which get added by the emulation code
itself.
> Do we not transfer ICC_SRE_EL1 because it's implemented as RO?
> (I think that's right for no-irq/fiq-bypass, sysregs only.)
Yes, also because looks like KVM is not going to implement GICv3 with non-SRE
mode, instead, if we want to run a legacy guest, we just configure our host to
provide GICv2 for it.
I actually migrate only those CPU interface registers, which are saved by the
kernel code as part of guest's context.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
