All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Avi Kivity <avi@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"yongjie.ren@intel.com" <yongjie.ren@intel.com>
Subject: Re: [PATCH] KVM: Use IRQF_ONESHOT for assigned device MSI interrupts
Date: Fri, 08 Jun 2012 10:03:42 +0200	[thread overview]
Message-ID: <4FD1B1DE.9080303@siemens.com> (raw)
In-Reply-To: <20120608080058.GB524@redhat.com>

On 2012-06-08 10:00, Michael S. Tsirkin wrote:
> On Fri, Jun 08, 2012 at 09:55:01AM +0200, Jan Kiszka wrote:
>> On 2012-06-08 09:47, Michael S. Tsirkin wrote:
>>> On Mon, Jun 04, 2012 at 01:40:28PM +0200, Jan Kiszka wrote:
>>>> On 2012-06-04 13:21, Thomas Gleixner wrote:
>>>>> On Sun, 3 Jun 2012, Avi Kivity wrote:
>>>>>
>>>>>> On 06/01/2012 09:26 PM, Jan Kiszka wrote:
>>>>>>>
>>>>>>>> you suggesting we need a request_edge_threaded_only_irq() API?  Thanks,
>>>>>>>
>>>>>>> I'm just wondering if that restriction for threaded IRQs is really
>>>>>>> necessary for all use cases we have. Threaded MSIs do not appear to me
>>>>>>> like have to be handled that conservatively, but maybe I'm missing some
>>>>>>> detail.
>>>>>>>
>>>>>>
>>>>>> btw, I'm hoping we can unthread assigned MSIs.  If the delivery is
>>>>>> unicast, we can precalculate everything and all the handler has to do is
>>>>>> set the IRR, KVM_REQ_EVENT, and kick the vcpu.  All of these can be done
>>>>>> from interrupt context with just RCU locking.
>>>>>
>>>>> There is really no need to run MSI/MSI-X interrupts threaded for
>>>>> KVM. I'm running the patch below for quite some time and it works like
>>>>> a charm.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> 	tglx
>>>>> ----
>>>>> Index: linux-2.6/virt/kvm/assigned-dev.c
>>>>> ===================================================================
>>>>> --- linux-2.6.orig/virt/kvm/assigned-dev.c
>>>>> +++ linux-2.6/virt/kvm/assigned-dev.c
>>>>> @@ -105,7 +105,7 @@ static irqreturn_t kvm_assigned_dev_thre
>>>>>  }
>>>>>  
>>>>>  #ifdef __KVM_HAVE_MSI
>>>>> -static irqreturn_t kvm_assigned_dev_thread_msi(int irq, void *dev_id)
>>>>> +static irqreturn_t kvm_assigned_dev_msi_handler(int irq, void *dev_id)
>>>>>  {
>>>>>  	struct kvm_assigned_dev_kernel *assigned_dev = dev_id;
>>>>>  
>>>>> @@ -117,7 +117,7 @@ static irqreturn_t kvm_assigned_dev_thre
>>>>>  #endif
>>>>>  
>>>>>  #ifdef __KVM_HAVE_MSIX
>>>>> -static irqreturn_t kvm_assigned_dev_thread_msix(int irq, void *dev_id)
>>>>> +static irqreturn_t kvm_assigned_dev_msix_handler(int irq, void *dev_id)
>>>>>  {
>>>>>  	struct kvm_assigned_dev_kernel *assigned_dev = dev_id;
>>>>>  	int index = find_index_from_host_irq(assigned_dev, irq);
>>>>> @@ -346,9 +346,8 @@ static int assigned_device_enable_host_m
>>>>>  	}
>>>>>  
>>>>>  	dev->host_irq = dev->dev->irq;
>>>>> -	if (request_threaded_irq(dev->host_irq, NULL,
>>>>> -				 kvm_assigned_dev_thread_msi, 0,
>>>>> -				 dev->irq_name, dev)) {
>>>>> +	if (request_irq(dev->host_irq, kvm_assigned_dev_msi_handler, 0,
>>>>> +			dev->irq_name, dev)) {
>>>>>  		pci_disable_msi(dev->dev);
>>>>>  		return -EIO;
>>>>>  	}
>>>>> @@ -373,9 +372,9 @@ static int assigned_device_enable_host_m
>>>>>  		return r;
>>>>>  
>>>>>  	for (i = 0; i < dev->entries_nr; i++) {
>>>>> -		r = request_threaded_irq(dev->host_msix_entries[i].vector,
>>>>> -					 NULL, kvm_assigned_dev_thread_msix,
>>>>> -					 0, dev->irq_name, dev);
>>>>> +		r = request_irq(dev->host_msix_entries[i].vector,
>>>>> +				kvm_assigned_dev_msix_handler, 0,
>>>>> +				dev->irq_name, dev);
>>>>>  		if (r)
>>>>>  			goto err;
>>>>>  	}
>>>>
>>>> This may work in practice but has two conceptual problems:
>>>>  - we do not want to run a potential broadcast to all VCPUs to run in
>>>>    a host IRQ handler
>>>>  - crazy user space could have configured the route to end up in the
>>>>    PIC or IOAPIC, and both are not hard-IRQ safe (this should probably
>>>>    be caught on setup)
>>>>
>>>> So this shortcut requires some checks before being applied to a specific
>>>> MSI/MSI-X vector.
>>>
>>> I did this in the past:
>>> https://lkml.org/lkml/2012/1/18/287
>>>
>>> Have no hw to test this atm but if there are any takers
>>> wanting to play with it I can update and post.
>>
>> Just add check that allow only unicasts, and this should be fine.
>>
>> Jan
> 
> If I code it up you can test it?

Yep, no problem.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2012-06-08  8:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-01 16:16 [PATCH] KVM: Use IRQF_ONESHOT for assigned device MSI interrupts Alex Williamson
2012-06-01 16:39 ` Jan Kiszka
2012-06-01 17:03   ` Alex Williamson
2012-06-01 17:14     ` Jan Kiszka
2012-06-01 17:59       ` Alex Williamson
2012-06-01 18:26         ` Jan Kiszka
2012-06-03  8:42           ` Avi Kivity
2012-06-04 11:21             ` Thomas Gleixner
2012-06-04 11:40               ` Jan Kiszka
2012-06-04 13:07                 ` Thomas Gleixner
2012-06-04 13:16                   ` Jan Kiszka
2012-06-04 13:22                     ` Thomas Gleixner
2012-06-08  7:47                 ` Michael S. Tsirkin
2012-06-08  7:55                   ` Jan Kiszka
2012-06-08  8:00                     ` Michael S. Tsirkin
2012-06-08  8:03                       ` Jan Kiszka [this message]
2012-06-08 14:39                 ` Michael S. Tsirkin
2012-06-08 14:50                   ` Jan Kiszka
2012-06-11 10:01                     ` Avi Kivity
2012-06-11 10:21                       ` Michael S. Tsirkin
2012-06-18  8:46                         ` Ren, Yongjie
2012-06-18 11:00                         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD1B1DE.9080303@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=alex.williamson@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=yongjie.ren@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.