Re: [Qemu-devel] [PATCH RFC V5 1/9] hw/intc: Implement GIC-500 support files

[Shlomo Pongratz]

See inline.

On Wednesday, October 21, 2015, Pavel Fedin <address@hidden> wrote:
>  Hello!
>
> > I can't find the patch that handles the for example modification of "uint8_t sgi_pending[GIC_NR_SGIS][GIC_NCPU]" to fixed-size bitmaps. as
> > GIC_NCPU is not a constant and uint8_t need to have the size of nubmer of CPUs which is no longer bounded.
>
>  This is the only thing which i excluded, because my vGIC implementation didn't need these flags. I know that you cannot actually omit them in software emulation, because they are needed in order to handle a situation where more than one CPU sends the same SGI number.
>  I think you can place it in distributor, in "internal state" section, if you look at my patch.

I'll modify the reset along your suggestion.

 

> > Are you sure that the semantics is the same? In section 4.1.4 of GICv3 I see that the security level is a combination of two registers GRPMOD > and GROUP and I wanted to be prepared for it.
>
>  Looks like you have some private NDA version of the manual, because my one (downloaded from infocenter) doesn't have a paragraph numbered 4.1.4. Anyway, after reading my one, i think that GRPMOD simply overrides what is specified in GROUP. I cannot find such thing as "group 2" anywhere, and all the text starts with "In a GIC which supports two security states". So, there's only non-secure and secure state, nothing else.
>  Again, nothing changes since ARM32.

I'll re-examine the document and see if this is relevant.

> > I assume you want to distinguish between Secure EL1 and Secure EL3 (in the future).
>
>  As far as i understand, EL3 is what was called "monitor" in ARM32, and i would still prefer to call it this way, because it is more meaningful than those stupid (IMHO) numbers. The only special thing about this mode is that it allows you to freely switch between secure and non-secure states. So, again, there's nothing special about "secure EL3".
>
>  Peter, please correct me if i'm wrong.
>
> > I don't have access to the internal CPU's data structures in the GIC's core, its an opaque structure to the GIC.
> > Including the CPU include files doesn't seems to work.
>
>  See this: http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg02349.html. This is also a part of my live migration RFC.
>  I remember that Peter told long time ago that "it should really be a property", when i integrated full affinity support. But, he currently refused to accept this small standalone patch because there are no users for now. My GICv3 live migration is waiting for kernel API to be ready. And kernel API is waiting for kernel 4.5 development cycle to begin.

So please resubmit it and mention me as a client.

But I wonder if accessing the property in real time (not in only in initialization) from the GIC code will have impact on performance. 

> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia