From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v3 16/16] xen/arm: add SGI handling for GICv3 Date: Tue, 06 May 2014 10:42:06 +0100 Message-ID: <5368AE6E.7060007@linaro.org> References: <1397560675-29861-1-git-send-email-vijay.kilari@gmail.com> <1397560675-29861-17-git-send-email-vijay.kilari@gmail.com> <535188FD.1020408@linaro.org> <5363AB0F.8040308@linaro.org> <1399043882.18944.8.camel@kazak.uk.xensource.com> <5363B89A.4090909@linaro.org> <5367DB1F.7040503@linaro.org> <1399366728.3014.27.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1399366728.3014.27.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Vijay Kilari , Stefano Stabellini , Prasun Kapoor , Vijaya Kumar K , xen-devel@lists.xen.org, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 06/05/14 09:58, Ian Campbell wrote: > On Mon, 2014-05-05 at 19:40 +0100, Julien Grall wrote: > >> As secure interrupt should not happen from the guest. > > Surely it would be a silicon bug if it did, a secure interrupt should be > trapping to Secure EL3 not to NS EL2. What exactly are you asking Vijay > to handle here? With GICv3 it's possible to generate an SGI for another security state (see ICC_ASGI1R_EL1). We have to handle it like we do for smc call. > >> You can check that >> we correctly trap the access to thoses interrupts. > > "trap access to interrupts" is meaningless AFAICT. Do you perhaps mean > "trap access to the XXX registers". For which XXX? Sorry, it's because theses registers is used to send an SGI. I think we have to trap ICC_ASGI1R_EL1, maybe ICC_SGI0R_EL1, just in case. >>>> The GICv3 spec requests to send a UNDEF exception if the register is not >>>> implemented. >>>> >>>> In general way, I think UNDEF is a best solution as some kernel such as >>>> Linux is able to recover from an undef on some specific access (it's >>>> actually the case for some debug registers on ARM32). >>> >>> In my understanding, calling inject_undef64_exception() will generate >>> UNDEF to guest. >> >> Right. You have to call this function only if the domain is arm aarch64 >> guest. >> >> AFAIU, it's possible to have GICv3 support when the guest is armv8 32 >> bit. > > Is it? How do the system registers map onto the 32bit CP registers? On aarch32, you can access to system registers via mrs/msr. GICv3 is not mapped onto 32bit CP registers because there is a limited number of encodings available. Regards, -- Julien Grall