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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 13, 2010 at 08:58:27AM +0800, Sheng Yang wrote:
> 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@xxxxxxxxxxxxxxx>
> > > > > > 
> > > > > > 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.

Yes, I didn't make this clear: no problem with the interface:
just add a way to mask the vector. It is just that the implementation
proposed only works for interrupts used by assigned devices. I would like
for it to work for irqfd as well. Your patch would not work for this case.

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

What I was trying to suggest is one of 2 options:

1.	mask the vector in the device.
	Basically we just want an API to force mask directly
	instead of waiting for an interrupt.

	As you say this needs core linux changes so it might be harder,
	but the advantage is that we follow the guest closely.

2.	assuming 1 is just too hard to implement, here's option 2:
	keep existing patch, but make irqfd work

	Have an ioctl to set a flag in the routing table in KVM,
	consult this flag when you are injecting the interrupt,
	if masked set pending bit. When unmasked test and clear pending bit and
	reinject if it was set.


Hope this helps.

> --
> regards
> Yang, Sheng
--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux