Re: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 23/10/2020 01:02, Stefano Stabellini wrote:
> On Thu, 22 Oct 2020, Julien Grall wrote:
> > > > On 20/10/2020 16:25, Rahul Singh wrote:
> > > > > Add support for ARM architected SMMUv3 implementations. It is based on
> > > > > the Linux SMMUv3 driver.
> > > > > Major differences between the Linux driver are as follows:
> > > > > 1. Only Stage-2 translation is supported as compared to the Linux driver
> > > > >      that supports both Stage-1 and Stage-2 translations.
> > > > > 2. Use P2M  page table instead of creating one as SMMUv3 has the
> > > > >      capability to share the page tables with the CPU.
> > > > > 3. Tasklets is used in place of threaded IRQ's in Linux for event queue
> > > > >      and priority queue IRQ handling.
> > > > Tasklets are not a replacement for threaded IRQ. In particular, they will
> > > > have priority over anything else (IOW nothing will run on the pCPU until
> > > > they are done).
> > > >
> > > > Do you know why Linux is using thread. Is it because of long running
> > > > operations?
> > > Yes you are right because of long running operations Linux is using the
> > > threaded IRQs.
> > >
> > > SMMUv3 reports fault/events bases on memory-based circular buffer queues not
> > > based on the register. As per my understanding, it is time-consuming to
> > > process the memory based queues in interrupt context because of that Linux
> > > is using threaded IRQ to process the faults/events from SMMU.
> > >
> > > I didn’t find any other solution in XEN in place of tasklet to defer the
> > > work, that’s why I used tasklet in XEN in replacement of threaded IRQs. If
> > > we do all work in interrupt context we will make XEN less responsive.
> > So we need to make sure that Xen continue to receives interrupts, but we also
> > need to make sure that a vCPU bound to the pCPU is also responsive.
> >
> > > If you know another solution in XEN that will be used to defer the work in
> > > the interrupt please let me know I will try to use that.
> > One of my work colleague encountered a similar problem recently. He had a long
> > running tasklet and wanted to be broken down in smaller chunk.
> >
> > We decided to use a timer to reschedule the taslket in the future. This allows
> > the scheduler to run other loads (e.g. vCPU) for some time.
> >
> > This is pretty hackish but I couldn't find a better solution as tasklet have
> > high priority.
> >
> > Maybe the other will have a better idea.
> Julien's suggestion is a good one.
>
> But I think tasklets can be configured to be called from the idle_loop,
> in which case they are not run in interrupt context?
Tasklets can either run from the IDLE loop or from a softirq context.

When running from a softirq context is may happen on return from 
receiving an interrupt. However, interrupts will always be enabled.
So I am not sure what concern you are trying to raise here.

Cheers,

--
Julien Grall