Re: [Xen-devel] [PATCH v7 4/6] xen/arm: zynqmp: implement zynqmp_eemi

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 18/12/2018 22:36, Stefano Stabellini wrote:
> On Tue, 18 Dec 2018, Julien Grall wrote:
> > Hi,
> >
> > On 12/17/18 10:10 PM, Stefano Stabellini wrote:
> > > +    /* These calls are safe and always allowed.  */
> > > +    case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
> > > +    case EEMI_FID(ZYNQMP_SIP_SVC_UID):
> > > +    case EEMI_FID(ZYNQMP_SIP_SVC_VERSION):
> > > +    case EEMI_FID(PM_GET_TRUSTZONE_VERSION):
> > > +    case EEMI_FID(PM_GET_API_VERSION):
> > Above you say the call to PM_GET_API_VERSION are safe and always allowed. But
> > looking at the ATF implementation the first call to PM_GET_API_VERSION will
> > enable IPI IRQ.
> >
> > AFAICT, Dom0 will be the only domain to access IPI. So what happen if, in the
> > Dom0less case, the guest is booting before and calling PM_GET_API_VERSION?
> >
> > I haven't looked in depth the other SIP functions to see whether there are
> > other potential issue.
> On Xilinx MPSoC, the power management handler runs on a separate
> processor (a Microblaze processor). Xilinx calls it "PMU". The IPI IRQ
> enabled by ATF is for it to communicate with the PMU, it should not be
> exposed to virtual machines. Nothing to do on our side here.
I am a bit confused, this does not seems to match the comment in the ATF code:
                /*
                 * Enable IPI IRQ
                 * assume the rich OS is OK to handle callback IRQs now.
                 * Even if we were wrong, it would not enable the IRQ in
                 * the GIC.
                 */

What would happen if a guest is calling PM_GET_API_VERSION and we are not ready 
to handle callback?
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel