Re: [Xen-devel] [RFC v3 2/6] xen/arm: Add save/restore support for ARM GIC V2

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-05-14 at 14:23 +0200, Tim Deegan wrote:
> > >> +
> > >> +/* Info for hypervisor to manage guests (per-vcpu)
> > >> + *   - Based on GICv2
> > >> + *   - Mainly store registers of GICH_*
> > >> + */
> > >> +struct hvm_arm_gich_v2
> > >> +{
> > >> +    uint32_t gic_hcr;
> > >> +    uint32_t gic_vmcr;
> > >> +    uint32_t gic_apr;
> > >> +    uint32_t gic_lr[64];
> > >> +    uint64_t event_mask;
> > >> +    uint64_t lr_mask;
> > > 
> > > I don't think you should be saving any GICH state at all. What should be
> > > saved is the corresponding GICC state, i.e. "architectural state" that
> > > is observed by the guest. This might mean pickling stuff from the GICH
> > > state into a GICC form. (I said this wrt the LRs in a previous round of
> > > review)
> > 
> > What are the advantage to save the GICC state rather than GICH?
> > 
> > IIRC, the GICH state gives you a representation of the important bits of
> > the GICC. Most of GICC can't be restore without any translation and
> > writing in GICH (see gic_vmcr that is a collection of multiple GICC
> > registers). It seems easier to use GICH state during migration.
> 
> The GICC state is the architectural state of the virtual machine;
> the GICH state is an implementation detail of how that's achieved by Xen.
> We prefer always to put clean architectural state into the save record.
> That way if we for any reason change how the VMM is implemented, the
> save record format won't be affected by that.

Ack.

> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel