See inline. On Wednesday, October 21, 2015, Pavel Fedin <p.fe...@samsung.com> 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 > > >
