On 30/10/2015 07:16, Yunhong Jiang wrote:
> And with this change, we even don't need the module option anymore, we first
> try the primary handler, which is in hard irq context, and if failed, then
> threaded irq handler. Am I right?
Yes.
> Paolo/Alex, do you want to work on the patch yourself
On Thu, Oct 29, 2015 at 10:45:44AM +0100, Paolo Bonzini wrote:
>
>
> On 29/10/2015 04:11, Alex Williamson wrote:
> > > The irqfd is already able to schedule a work item, because it runs with
> > > interrupts disabled, so I think we can always return IRQ_HANDLED.
> >
> > I'm confused by this. The
On 29/10/2015 04:11, Alex Williamson wrote:
> > The irqfd is already able to schedule a work item, because it runs with
> > interrupts disabled, so I think we can always return IRQ_HANDLED.
>
> I'm confused by this. The problem with adding IRQF_NO_THREAD to our
> current handler is that it hits
On Wed, 2015-10-28 at 18:05 +0100, Paolo Bonzini wrote:
>
> On 28/10/2015 17:00, Alex Williamson wrote:
> > > Alex, would it make sense to use the IRQ bypass infrastructure always,
> > > not just for VT-d, to do the MSI injection directly from the VFIO
> > > interrupt handler and bypass the eventf
On Wed, Oct 28, 2015 at 06:05:00PM +0100, Paolo Bonzini wrote:
>
>
> On 28/10/2015 17:00, Alex Williamson wrote:
> > > Alex, would it make sense to use the IRQ bypass infrastructure always,
> > > not just for VT-d, to do the MSI injection directly from the VFIO
> > > interrupt handler and bypass
On Wed, Oct 28, 2015 at 12:18:48PM -0600, Alex Williamson wrote:
> On Wed, 2015-10-28 at 10:50 -0700, Yunhong Jiang wrote:
> > On Wed, Oct 28, 2015 at 01:44:55AM +0100, Paolo Bonzini wrote:
>
> It's in linux-next via the kvm.git next branch:
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git
>
>
On 28/10/2015 18:50, Yunhong Jiang wrote:
> > No, I don't think you can use raw_spinlock there. The problem is not
> > just eventfd_signal, it is especially wake_up_locked_poll. You cannot
> > convert the whole workqueue infrastructure to use raw_spinlock.
>
> You mean the waitqueue, instead o
On Wed, 2015-10-28 at 10:50 -0700, Yunhong Jiang wrote:
> On Wed, Oct 28, 2015 at 01:44:55AM +0100, Paolo Bonzini wrote:
> >
> >
> > On 27/10/2015 22:26, Yunhong Jiang wrote:
> > >> > On RT kernels however can you call eventfd_signal from interrupt
> > >> > context? You cannot call spin_lock_irq
On Wed, Oct 28, 2015 at 01:44:55AM +0100, Paolo Bonzini wrote:
>
>
> On 27/10/2015 22:26, Yunhong Jiang wrote:
> >> > On RT kernels however can you call eventfd_signal from interrupt
> >> > context? You cannot call spin_lock_irqsave (which can sleep) from a
> >> > non-threaded interrupt handler,
On 28/10/2015 17:00, Alex Williamson wrote:
> > Alex, would it make sense to use the IRQ bypass infrastructure always,
> > not just for VT-d, to do the MSI injection directly from the VFIO
> > interrupt handler and bypass the eventfd? Basically this would add an
> > RCU-protected list of consume
On Wed, 2015-10-28 at 01:44 +0100, Paolo Bonzini wrote:
>
> On 27/10/2015 22:26, Yunhong Jiang wrote:
> >> > On RT kernels however can you call eventfd_signal from interrupt
> >> > context? You cannot call spin_lock_irqsave (which can sleep) from a
> >> > non-threaded interrupt handler, can you?
On 27/10/2015 22:26, Yunhong Jiang wrote:
>> > On RT kernels however can you call eventfd_signal from interrupt
>> > context? You cannot call spin_lock_irqsave (which can sleep) from a
>> > non-threaded interrupt handler, can you? You would need a raw spin lock.
> Thanks for pointing this out.
On Tue, Oct 27, 2015 at 10:29:28AM +0100, Paolo Bonzini wrote:
>
>
> On 27/10/2015 07:35, Yunhong Jiang wrote:
> > On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote:
> >> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote:
> >>> An option to force VFIO PCI MSI/MSI-X handler as n
On 27/10/2015 07:35, Yunhong Jiang wrote:
> On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote:
>> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote:
>>> An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
>>> even when CONFIG_IRQ_FORCED_THREADING=y. This is uself
On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote:
> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote:
> > An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
> > even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when
> > assigning a device to a guest with
On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote:
> An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
> even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when
> assigning a device to a guest with low latency requirement since it
> reduce the context switch to/from the
An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when
assigning a device to a guest with low latency requirement since it
reduce the context switch to/from the IRQ thread.
An experiment was conducted on a HSW platform for 1
17 matches
Mail list logo
