Re: [Qemu-devel] [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode

[Michael S. Tsirkin]

On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
> On 2012-03-28 13:31, Michael S. Tsirkin wrote:
> >>>>> Also, how would this support irqfd in the future? Will we have to
> >>>>> rip it all out and replace with per-device tracking that we
> >>>>> have today?
> >>>>
> >>>> Irqfd and kvm device assignment will require additional interfaces (of
> >>>> the kvm core in QEMU) via which you will be able to request stable
> >>>> routes from such sources to specified MSIs. That will be widely
> >>>> orthogonal to what is done in these patches here.
> >>>
> >>> Yes but not exactly as they will conflict for resources, right?
> >>> How do you plan to solve this?
> >>
> >> As done in my original series: If a static route requires a pseudo GSI
> >> and there are none free, we simply flush the dynamic MSI routes.
> > 
> > Right. So static routes take precedence. This means that in effect
> > we will have two APIs in qemu: for fast MSIs and for slow ones,
> > the advantage of the slow APIs being that they are easier to use,
> > right?
> 
> We will have two APIs depending on the source of the MSI. Special
> sources are the exception while emulated ones are the majority. And for
> the latter we should try very hard to keep things simple and clean.
> 
> Jan

I assume this means yes :) So how about we replace the hash table with a
single GSI reserved for this purpose, and use that for each interrupt?
This will work fine for slow paths such as hotplug controller, yes it
will be slow but *predictably* slow.

Fast path will use static GSIs like qemu-kvm does.


> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux