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

[Pavel Fedin]

 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.

> 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 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.

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