Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

[Julien Grall <julien@xxxxxxx>]

On 07/04/2020 17:50, Julien Grall wrote:
> On 07/04/2020 17:16, George Dunlap wrote:
> > > On Apr 6, 2020, at 7:47 PM, Julien Grall <julien@xxxxxxx> wrote:
> > >
> > > On 06/04/2020 18:58, George Dunlap wrote:
> > > > > On Apr 3, 2020, at 9:27 PM, Julien Grall 
> > > > > <julien.grall.oss@xxxxxxxxx> wrote:
> > > > > On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini 
> > > > > <sstabellini@xxxxxxxxxx> wrote:
> > > > > > On Thu, 2 Apr 2020, Julien Grall wrote:
> > > > > > > As we discussed on Tuesday, the cost for other vCPUs is only 
> > > > > > > going to be a
> > > > > > > trap to the hypervisor and then back again. The cost is likely 
> > > > > > > smaller than
> > > > > > > receiving and forwarding an interrupt.
> > > > > > >
> > > > > > > You actually agreed on this analysis. So can you enlighten me as 
> > > > > > > to why
> > > > > > > receiving an interrupt is a not problem for latency but this is?
> > > > > > My answer was that the difference is that an operating system can
> > > > > > disable interrupts, but it cannot disable receiving this special IPI.
> > > > > An OS can *only* disable its own interrupts, yet interrupts will still
> > > > > be received by Xen even if the interrupts are masked at the processor
> > > > > (e.g local_irq_disable()).
> > > > >
> > > > > You would need to disable interrupts one by one as the GIC level (use
> > > > > ICENABLER) in order to not receive any interrupts. Yet, Xen may still
> > > > > receive interrupts for operational purposes (e.g serial, console,
> > > > > maintainance IRQ...). So trap will happen.
> > > > I think Stefano’s assertion is that the users he has in mind will be 
> > > > configuring the system such that RT workloads get a minimum number 
> > > > of hypervisor-related interrupts possible.  On a 4-core system, you 
> > > > could  have non-RT workloads running on cores 0-1, and RT workloads 
> > > > running with the NULL scheduler on cores 2-3.  In such a system, 
> > > > you’d obviously arrange that serial and maintenance IRQs are 
> > > > delivered to cores 0-1.
> > > Well maintenance IRQs are per pCPU so you can't route to another one...
> > >
> > > But, I think you missed my point that local_irq_disable() from the 
> > > guest will not prevent the hypervisor to receive interrupts *even* 
> > > the one routed to the vCPU itself. They will just not be delivered to 
> > > the guest context until local_irq_enable() is called.
> > My understanding, from Stefano was that what his customers are 
> > concerned about is the time between the time a physical IRQ is 
> > delivered to the guest and the time the guest OS can respond 
> > appropriately.  The key thing here isn’t necessarily speed, but 
> > predictability — system designers need to know that, with a high 
> > probability, their interrupt routines will complete within X amount of 
> > cycles.
> > Further interrupts delivered to a guest are not a problem in this 
> > scenario, if the guest can disable them until the critical IRQ has 
> > been handled.
> You keep saying a guest can disable interrupts, but it can't do it via 
> local_irq_disable(). So what method are you thinking? Disabling at the 
> GIC level? That is involving traps and most likely not going to help 
> with predictability...
Just to clear I meant interrupts to be received by Xen including the one 
routed to that vCPU.
Cheers,

--
Julien Grall