[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH v1 03/10] xen/arm: move vgic data to vgic driver



On Mon, Mar 24, 2014 at 4:27 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Sat, 2014-03-22 at 14:50 +0530, Vijay Kilari wrote:
>> On Fri, Mar 21, 2014 at 10:53 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
>> wrote:
>> > On Thu, 2014-03-20 at 13:51 +0000, Julien Grall wrote:
>> >
>> >> >
>> >> > Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@xxxxxxxxxxxxxxxxxx>
>> >> > ---
>> >> >  xen/arch/arm/vgic.c          |   35 ++++++++++++++++++++++++++++-------
>> >> >  xen/include/asm-arm/domain.h |   13 ++-----------
>> >> >  2 files changed, 30 insertions(+), 18 deletions(-)
>> >> >
>> >> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> >> > index d2a13fb..694a15c 100644
>> >> > --- a/xen/arch/arm/vgic.c
>> >> > +++ b/xen/arch/arm/vgic.c
>> >> > @@ -35,6 +35,15 @@
>> >> >  /* Number of ranks of interrupt registers for a domain */
>> >> >  #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
>> >> >
>> >> > +/* Represents state corresponding to a block of 32 interrupts */
>> >> > +struct vgic_irq_rank {
>> >> > +    spinlock_t lock; /* Covers access to all other members of this 
>> >> > struct */
>> >> > +    uint32_t ienable, iactive, ipend, pendsgi;
>> >> > +    uint32_t icfg[2];
>> >> > +    uint32_t ipriority[8];
>> >> > +    uint32_t itargets[8];
>> >> > +};
>> >> > +
>> >>
>> >> I would move the definition in a vgic_v2.h
>> >
>> OK
>>
>> > Is there going to be lots of this stuff which is different for the two?
>> > I'd rather wait and see how unwieldy gic.h gets first.
>>
>> For now, the difference is in v3 uint32_t  itargets[8] is replaced
>> with u64 itargets[32]
>
> But the rest of the state remains the same?
>
> If that is the case then I don't think there is any reason to split this
> struct into v2 and v3 versions. Just keep a single struct with the
> larger itargets using v3 semantics and have the v2 driver do the obvious
> packing and unpacking.
>
  The complete vgic driver is based on this structure and with change in size
and number of registers for itargets register is not clean enough to manage
single vgic driver for both v2 & v3.

Anyway, we have separate vgic v2 & v3 driver and having two different
structures and it helps to manage it easily.

>> may be for v4 it other registers might differ
>
> Lets cross that bridge when we come to it.
>
> Ian.
>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.