Re: [Xen-devel] Question, How to share interrupt between Doms

[Julien Grall <julien.grall@xxxxxxx>]

On 08/10/2018 03:37, Peng Fan wrote:
> Hi Julien
Hi Peng,

> > -----Original Message-----
> > From: Julien Grall [mailto:julien.grall@xxxxxxx]
> > Sent: 2018年10月5日 1:27
> > To: Peng Fan <peng.fan@xxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Andre Przywara
> > <andre.przywara@xxxxxxx>
> > Subject: Re: Question, How to share interrupt between Doms
> >
> >
> > Hi Peng,
> >
> > On 04/10/2018 02:12, Peng Fan wrote:
> > > > -----Original Message-----
> > > > From: Julien Grall [mailto:julien.grall@xxxxxxx]
> > > > Sent: 2018年10月3日 0:03
> > > > To: Peng Fan <peng.fan@xxxxxxx>; Stefano Stabellini
> > > > <sstabellini@xxxxxxxxxx>
> > > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Andre Przywara
> > > > <andre.przywara@xxxxxxx>
> > > > Subject: Re: Question, How to share interrupt between Doms
> > > >
> > > > On 02/10/2018 09:32, Peng Fan wrote:
> > > > > Hi Julien, Stefano,
> > > > Hi Peng,
> > > >
> > > > > Do you have any suggestions on how to share one interrupt between Doms?
> > > > Sharing interrupts are usually a pain. You would need to forward the
> > > > interrupts to all the domains using that interrupt and wait for them
> > > > to EOI. This has security implications because you don't want DomA to
> > > > prevent DomB receiving another interrupt because the previous one has not
> > been EOIed correctly.
> > > > > The issue is that a gpio controller has 32 in/out port, however it
> > > > > only has one
> > > > binded interrupt. The interrupt handler needs to check the status
> > > > bits to check which port has interrupt coming.
> > > > > In my case, there are different devices using gpio interrupt that
> > > > > needs to be
> > > > assigned to different doms.
> > > >
> > > >    From what you wrote, it looks like you expect the GPIO controller
> > > > to be shared with multiple domains.
> > > >
> > > > I don't think it is safe to do that. You need one domain (or Xen) to
> > > > fully manage the controller. All the other domain will have to access
> > > > either a virtual GPIO controller or PV one. In the former, interrupt
> > > > would be virtual, while the latter the interrupt would be through even
> > channel.
> > > > So sharing interrupt should not be necessary. Did I miss anything?
> > > When interrupts comes, the dom0 will handle that. Then forward the
> > interrupt to domu.
> > > But I did not find a good method to forward the interrupt and hook the
> > interrupt in domu dts and domu driver.
> > > In Domu, driver needs use request irq and the dts needs interrupt=<xx
> > > xx>. But  when dom0 notify remote, there is no hook in frontend driver and
> > the other driver interrupt handler.
> >
> > You say that Dom0 will receive the interrupt. So Dom0 is access directly the
> > GPIO controller. Right?
> Yes.
>
> > What about the guests? Do they access directly the GPIO controller? Or did you
> > introduce a PV protocol for this?
> Guest use PV to access GPIO in Dom0.
> When interrupt comes to dom0, the pv use event channel to forward the interrupt 
> to Domu,
> I did not find a good way to do interrupt forwarding and let domu handle the 
> interrupt as without
> Virtualization.
Do you mean using a SPIs rather than an event channel to deliver the 
interrupt to the guest?
> I use generic_handle_irq() when frontent received the forwarded interrupt from 
> dom0
> in a eventchannel interrupt, but no work.
Do you see any error? Would it be possible to paste logs?

> Another issue is in backend, request_threaded_irq for the gpio, some gpio will 
> trigger interrupt before
> domu could handle the interrupt, this is because gpio default status or some on 
> board devices pull up/down
> the gpio.
I am not sure to understand the issue with that. It should not be 
different from the hardware case. Would it be possible to expand it?
--
Julien Grall

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