> From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel Vetter > Sent: Tuesday, September 30, 2014 3:30 AM > > On Tue, Sep 30, 2014 at 06:05:37PM +0800, Jike Song wrote: > > vgt owns the hardware interrupt of the GPU, to satisfy the > > interrupt requirement from both host side and guest side > > (e.g. host may have MI_USER_INTERRUPT disabled, while a VM > > may have it enabled). Sometimes vgt may also need to emulate > > a virtual interrupt to the host, w/o a hardware interrupt > > actually triggered. So we need to split the handling > > between physical interrupts to vgt and virtual interrupts > > to host i915. > > > > Regarding to above requirements, this patch registers a > > vgt interrupt handler when vgt is enabled, while letting > > original i915 interrupt handler instead carried in a > > tasklet. Whenever a virtual interrupt needs to be injected > > to host i915, tasklet_schedule gets called. > > So the tasklet requirement comes from being able to inject interrupts on > the host side from vgt to i915? yes. > > Why would you ever need to do that instead of just either calling the i915 > irq handler as the tail handler from hardirq context or directly calling > whatever function you want to call anywhere else? > > I guess we need even more information here about the design ;-) > We want to separate pirq and virq handling in a consistent way for both host and guest side. In pirq handler, it simply checks physical pending events, and loop all VM's virtual imr/ier to decide whether to pend virtual iir. At the end of pirq handling, kick off an asynchronous event to either host i915 or guest i915, if there's pending virtual iir, in the same manner as how a physical interrupt is triggered. For guest virq injection, the kick-off goes through APIC emulation to deliver to guest i915. For host virq injection, we choose tasklet now to implement the asynchronous manner. But definitely tasklet is not hardirq context, so there's some limitation. Similarly asynchronous manner is required when emulating a register access, e.g. to execlist submission port, which may trigger a virtual interrupt. Invoking i915 interrupt handler in the emulation path may cause tricky lock problem, since i915 handler also accesses registers which further causes nested emulations. >From virtualization p.o.v, the ideal case is to run host i915 irq handler in the interrupt context, which meets all the assumption from original code. Using tasklet or other manner still has some restriction. This is a major open we'd like to hear more from you guys. Is it possible to have i915 driver to request two irq numbers: irq1 for real device and irq2 is purely faked one. vgt handler registers on irq1 and i915 hanlder registers on irq2, and then we can use self IPI to trigger irq2 when injection is required. But I'm not sure whether this is an existing feature in kernel, or need some core enhancement in irq sub-system... Thanks Kevin _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
