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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
