[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 03/15] arm/xen: move gic save and restore registers to gic driver
On Wed, Apr 9, 2014 at 10:21 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > On Fri, 2014-04-04 at 17:26 +0530, vijay.kilari@xxxxxxxxx wrote: > >> gic saved registers are moved to gic driver. >> This required structure is allocated at runtime >> and is saved & restored. > > I don't follow why this change required switch to allocating them > dynamically. If it is a v2 vs v3 thing then I think a union in struct > arch_vcpu would be fine, unless the v3 stuff is relatively enormous. > v2: struct gic_state_data { uint32_t gic_hcr, gic_vmcr; uint32_t gic_apr; uint32_t gic_lr[64]; }; v3: struct gic_state_data { uint32_t gic_hcr, gic_vmcr; uint32_t gic_apr0[4]; uint32_t gic_apr1[4]; uint64_t gic_lr[16]; }; Except hcr & vmcr registers, v2 & v3 are different. Does static allocation helps in caching the domain struct and is this the reason for not choosing dynamic allocation? If so, I would suggest to move this structure to gic.h without dynamic allocation? >> - v->arch.gic_apr = GICH[GICH_APR]; >> - v->arch.gic_vmcr = GICH[GICH_VMCR]; >> + v->arch.gic_state->gic_apr = GICH[GICH_APR]; >> + v->arch.gic_state->gic_vmcr = GICH[GICH_VMCR]; > > I think the gic on the field name is now redundant, at I reckon you can > drop _state too. > > IOW v->arch.gic->apr, v->arch.gic->vmcr, etc. > > (or v->arch.gic.v2.apr / v->arch.gic_v2.apr based on the first comment) > > Ian. > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |