From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zoriu-0000dB-BN for qemu-devel@nongnu.org; Wed, 21 Oct 2015 07:38:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zoris-00036m-FZ for qemu-devel@nongnu.org; Wed, 21 Oct 2015 07:38:28 -0400 Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:38107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zoris-00036b-5g for qemu-devel@nongnu.org; Wed, 21 Oct 2015 07:38:26 -0400 Received: by wicll6 with SMTP id ll6so69934533wic.1 for ; Wed, 21 Oct 2015 04:38:25 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <00f601d10bed$fd8ac5e0$f8a051a0$@samsung.com> References: <1445396964-21189-1-git-send-email-shlomopongratz@gmail.com> <009e01d10bcc$8c4326a0$a4c973e0$@samsung.com> <00f601d10bed$fd8ac5e0$f8a051a0$@samsung.com> Date: Wed, 21 Oct 2015 14:38:25 +0300 Message-ID: From: Shlomo Pongratz Content-Type: multipart/alternative; boundary=e89a8f3bb07d05993505229bd17c Subject: Re: [Qemu-devel] [PATCH RFC V5 1/9] hw/intc: Implement GIC-500 support files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Fedin Cc: "peter.maydell@linaro.org" , "eric.auger@linaro.org" , Shlomo Pongratz , "qemu-devel@nongnu.org" , "shannon.zhao@linaro.org" , "ashoks@broadcom.com" , "imammedo@redhat.com" --e89a8f3bb07d05993505229bd17c Content-Type: text/plain; charset=UTF-8 See inline. On Wednesday, October 21, 2015, Pavel Fedin 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 > > > --e89a8f3bb07d05993505229bd17c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See inline.

On Wednesday, October 21, 2015, Pavel Fedin <p.fedin@samsung.com> wrote:
=C2=A0Hello!

> I can't find the patch that handles the for example modification o= f "uint8_t sgi_pending[GIC_NR_SGIS][GIC_NCPU]" to fixed-size bitm= aps. as
> GIC_NCPU is not a constant and uint8_t need to have the size of nubmer= of CPUs which is no longer bounded.

=C2=A0This is the only thing which i excluded, because my vGIC implementati= on didn't need these flags. I know that you cannot actually omit them i= n software emulation, because they are needed in order to handle a situatio= n where more than one CPU sends the same SGI number.
=C2=A0I 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.
=C2=A0
> 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.

=C2=A0Looks like you have some private NDA version of the manual, because m= y one (downloaded from infocenter) doesn't have a paragraph numbered 4.= 1.4. Anyway, after reading my one, i think that GRPMOD simply overrides wha= t is specified in GROUP. I cannot find such thing as "group 2" an= ywhere, and all the text starts with "In a GIC which supports two secu= rity states". So, there's only non-secure and secure state, nothin= g else.
=C2=A0Again, nothing changes since ARM32.


I'll re-examine the document and s= ee if this is relevant.

> I assume you want to distinguish between Secure EL1 and Secure EL3 (in= the future).

=C2=A0As 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 me= aningful than those stupid (IMHO) numbers. The only special thing about thi= s mode is that it allows you to freely switch between secure and non-secure= states. So, again, there's nothing special about "secure EL3"= ;.

=C2=A0Peter, please correct me if i'm wrong.

> I don't have access to the internal CPU's data structures in t= he GIC's core, its an opaque structure to the GIC.
> Including the CPU include files doesn't seems to work.

=C2=A0See this: http://lists.nongnu.org/archive/ht= ml/qemu-devel/2015-10/msg02349.html. This is also a part of my live mig= ration RFC.
=C2=A0I remember that Peter told long time ago that "it should really = be a property", when i integrated full affinity support. But, he curre= ntly refused to accept this small standalone patch because there are no use= rs 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.
<= div>But I wonder if accessing the property in real time (not in only in ini= tialization) from the GIC code will have impact on performance.=C2=A0
=

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


--e89a8f3bb07d05993505229bd17c--