qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 11/24] cpu/a15mpcore: Embed GICState


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v3 11/24] cpu/a15mpcore: Embed GICState
Date: Thu, 22 Aug 2013 12:41:10 +0100

On 22 August 2013 11:56, Andreas Färber <address@hidden> wrote:
> Am 21.08.2013 23:05, schrieb Peter Maydell:
> Not sure if a union of only one member is permitted? We're not actually
> accessing the GICState, only void* and DEVICE()/SYS_BUS_DEVICE(), so it
> just needs to block the memory, hopefully without needing to distinguish
> between ->gic.emulated and ->gic.kvm pointers.

Yes, but we need to actually have the right amount of memory
even if we don't care which of the subclasses this is. When
we were just storing a pointer this worked fine, because we
effectively deferred to the "create me a Foo" code to allocate
the right amount of memory for the specific object it returned.

> The decision doesn't depend on any user-settable property, just on the
> at this point global kvm_enabled() state, so I see nowhere else to
> allocate it dynamically.
>
> If you change the .instance_size struct one of the GICs uses, then a
> number of places will need to be reviewed, including
> ARM_GIC_COMMON()[*], ARM_GIC() and KVM_ARM_GIC() all returning the same
> type.

Yes, but those are part of the implementation, not the users,
and also they will be easy to find because there will be compile
errors where we've changed the type returned by one of those
macros but we haven't updated the callsite. (Conversely, users
which don't care which specific subclass they're dealing with
can continue to use the struct and macro corresponding to
the common base class.)

If there was a variant of object_initialize() that checked that
sizeof(*obj) was at least as big as the size of the object
instance that would be useful. (Would need to be a macro,
and I think we'd need to expose a function for "how big is
this type anyway").

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]