Re: [PATCH] KVM: Allow host IRQ sharing for assigned PCI 2.3 devices

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jan 10, 2012 at 10:18:12PM +0100, Jan Kiszka wrote:
> On 2012-01-10 21:44, Michael S. Tsirkin wrote:
> > On Tue, Jan 10, 2012 at 08:40:59PM +0100, Jan Kiszka wrote:
> >> On 2012-01-10 20:04, Michael S. Tsirkin wrote:
> >>>>>  But IMO this
> >>>>> shows it is a more generic interface.
> >>>>
> >>>> I'm worried about adding something new that will soon become obsolete
> >>>> again. That's wasted effort IMHO unless we say today that there will be
> >>>> no in-kernel MSI-X support.
> >>>>
> >>>> Jan
> >>>
> >>> Yes. But as we are adding a new interface maybe it's better to add a
> >>> more generic one? I don't insist as I don't have a specific proposal,
> >>> just something to consider.
> >>
> >> I could imagine defining an extensible IRQ masking interface, e.g. with
> >> flags that select the type, but only implementing it for INTx for now.
> >>
> >> Jan
> >>
> > 
> > I guess if we pass in the IRQ# the type can be inferred and does not
> > need to be passed in.
> 
> What kind of number, a GSI? We do not yet track what is behind a GSI, do we?
> 
> Hmm, I think this requires more careful thoughts. What should be the
> semantic of "mask" for the addressed device behind the IRQ? For assigned
> legacy IRQ it's clear: mask at config space level. For assigned MSI-X it
> should be masking at vector level. What about assigned MSI?
> What about
> irqfds? How to deal with future IRQ sources?

For correctness, it is enough to mask in host kernel.
Masking at device level is an optimization:
e.g. you don't mask immediately either.

> No, I think it is better to directly associate the masking feature
> directly with the source instead of doing this via some handle,
> potentially addressing the whole world. If there is a need for
> KVM_IRQFD_MASK, then let's introduce it. As a separate API.
> 
> Jan
> 

That's an option too.

-- 
MST