Re: [Xen-devel] [RFC PATCH 12/24] ARM: vGICv3: introduce basic ITS emulation bits

[Julien Grall <julien.grall@xxxxxxx>]

Hello Andre,

On 03/11/16 19:26, Andre Przywara wrote:
> On 24/10/16 16:31, Vijay Kilari wrote:
> > On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara <andre.przywara@xxxxxxx> wrote:
> > > +    switch ( info->gpa & 0xffff )
> > > +    {
> > > +    case VREG32(GITS_CTLR):
> > > +        if ( info->dabt.size != DABT_WORD ) goto bad_width;
> > > +        *r = vgic_reg32_extract(its->enabled | BIT(31), info);
> > > +       break;
> > > +    case VREG32(GITS_IIDR):
> > > +        if ( info->dabt.size != DABT_WORD ) goto bad_width;
> > > +        *r = vgic_reg32_extract(GITS_IIDR_VALUE, info);
> > > +        break;
> > > +    case VREG64(GITS_TYPER):
> > > +        if ( info->dabt.size < DABT_WORD ) goto bad_width;
> > > +        *r = vgic_reg64_extract(0x1eff1, info);
> >        GITS_TYPER.HCC is not set. Should be max vcpus of the domain
> HCC is clear on purpose. We want the guest to provide memory for
> everything that it allocates, to avoid it to hog Xen with allocations.
Whilst I agree that we want to limit the memory allocated by Xen itself,
each collection entry is just 16-bit. So unless we want to support a 
very big number of collection, I don't see any reason to request the 
guest to provision memory.
This makes the code more complex and you also have to validate the 
collection every time.
I remembered minimum number of collection an implementation has to 
support is "max_vcpus + 1" but I can't find again the statement in the spec.
Regards,

--
Julien Grall

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