Re: [PATCH 1/3] KVM: Emulation MSI-X mask bits for assigned devices

[Sheng Yang <sheng@linux.intel.com>]

On Wednesday 13 October 2010 02:30:30 Michael S. Tsirkin wrote:
> On Tue, Oct 12, 2010 at 02:49:58PM +0800, Sheng Yang wrote:
> > On Monday 11 October 2010 18:01:00 Michael S. Tsirkin wrote:
> > > On Mon, Oct 11, 2010 at 05:28:30PM +0800, Sheng Yang wrote:
> > > > On Sunday 03 October 2010 19:12:47 Michael S. Tsirkin wrote:
> > > > > On Tue, Sep 28, 2010 at 05:44:10PM +0800, Sheng Yang wrote:
> > > > > > This patch enable per-vector mask for assigned devices using
> > > > > > MSI-X.
> > > > > > 
> > > > > > Signed-off-by: Sheng Yang <sheng@linux.intel.com>
> > > > > 
> > > > > I think I see an issue here, noted below.  Some general comments:
> > > > > - The mask bit seems broken for injecting interrupts from
> > > > > 
> > > > >   userspace (with interrupts/ioctls).
> > > > >   I think we must test it on injection path.
> > > > 
> > > > I am not quite understand how it related to userspace interrupt
> > > > injection here... This patch only cover assigned devices for now.
> > > 
> > > Well, this is a kernel/userspace interface, if it's broken for
> > > userspace injection now we'll have to go through pain to fix it in a
> > > compatible way later when we want to use it for userspace injection.
> > > You might want to ask why we want the kernel to support making
> > > userspace-injected interrupts when userspace can just avoid injecting
> > > them, and the answer would be that with irqfd the injection might be
> > > handled in a separate process.
> > 
> > OK, I've understood how it related to userspace interrupt injection. But
> > I still can't see why the interface is broken...
> 
> That's easy to explain: mask vector, then inject interrupt with an ioctl or
> irqfd: it still goes in even though it's masked.

Lol... Obviously we have different definitions of the word "broken".

To my understanding, first, this interface is not new, just a part of old interface 
for assigned devices; and it covered current situation well. Second, this 
interface didn't cover your situation which doesn't exist currently. Third, this 
interface didn't prevent you from implementing solution for userspace interrupt 
injection mask in the future. So I don't understand how can you say it's "broken". 
Currently I think this interface is direct and elegant.

And could you elaborate your alternative way of doing this? Of course I would 
consider it.

--
regards
Yang, Sheng