Re: [PATCH 2/3] xen/arm: Defer GICv2 CPU interface mapping until the first access

[Julien Grall <julien@xxxxxxx>]

Hi,

On 27/01/2023 11:11, Henry Wang wrote:
> > -----Original Message-----
> > From: Michal Orzel <michal.orzel@xxxxxxx>
> > Subject: Re: [PATCH 2/3] xen/arm: Defer GICv2 CPU interface mapping until
> > the first access
> >
> > Hi Henry,
> >
> > On 16/01/2023 02:58, Henry Wang wrote:
> > > Note that GICv2 changes introduced by this patch is not applied to the
> > > "New vGIC" implementation, as the "New vGIC" is not used. Also since
> > The fact that "New vGIC" is not used very often and its work is in-progress
> > does not mean that we can implement changes resulting in a build failure
> > when enabling CONFIG_NEW_VGIC, which is the case with your patch.
> > So this needs to be fixed.
> I will add the "New vGIC" changes in v2.
>
> > > @@ -153,6 +153,8 @@ struct vgic_dist {
> > >       /* Base address for guest GIC */
> > >       paddr_t dbase; /* Distributor base address */
> > >       paddr_t cbase; /* CPU interface base address */
> > > +    paddr_t csize; /* CPU interface size */
> > > +    paddr_t vbase; /* virtual CPU interface base address */
> > Could you swap them so that base address variables are grouped?
> Sure, my original thought was grouping the CPU interface related fields but
> since you prefer grouping the base address, I will follow your suggestion.
I would actually prefer your approach because it is easier to associate 
the size with the base.
An alternative would be to use a structure to combine the base/size. So 
it is even clearer the association.
I don't have a strong opinion on either of the two approach I suggested.

Cheers,

--
Julien Grall