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? 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
Attachment:
signature.asc
Description: OpenPGP digital signature
