All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Zhu, Lingshan" <lingshan.zhu@intel.com>,
	mst@redhat.com, alex.williamson@redhat.com, pbonzini@redhat.com,
	sean.j.christopherson@intel.com, wanpengli@tencent.com
Cc: virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH V2 3/6] vDPA: implement IRQ offloading helpers in vDPA core
Date: Tue, 21 Jul 2020 10:51:44 +0800	[thread overview]
Message-ID: <8d12231e-aabe-317e-0afb-d680b866304b@redhat.com> (raw)
In-Reply-To: <8c9adead-d3a0-374e-e817-3cb5a44c4bda@intel.com>


On 2020/7/21 上午10:02, Zhu, Lingshan wrote:
>
>
> On 7/20/2020 5:40 PM, Jason Wang wrote:
>>
>> On 2020/7/20 下午5:07, Zhu, Lingshan wrote:
>>>>>
>>>>> +}
>>>>> +
>>>>> +static void vdpa_unsetup_irq(struct vdpa_device *vdev, int qid)
>>>>> +{
>>>>> +    struct vdpa_driver *drv = drv_to_vdpa(vdev->dev.driver);
>>>>> +
>>>>> +    if (drv->unsetup_vq_irq)
>>>>> +        drv->unsetup_vq_irq(vdev, qid);
>>>>
>>>>
>>>> Do you need to check the existence of drv before calling 
>>>> unset_vq_irq()?
>>> Yes, we should check this when we take the releasing path into account.
>>>>
>>>> And how can this synchronize with driver releasing and binding?
>>> Will add an vdpa_unsetup_irq() call in vhsot_vdpa_release().
>>> For binding, I think it is a new dev bound to the the driver,
>>> it should go through the vdpa_setup_irq() routine. or if it is
>>> a device re-bind to vhost_vdpa, I think we have cleaned up
>>> irq_bypass_producer for it as we would call vhdpa_unsetup_irq()
>>> in the release function.
>>
>>
>> I meant can the following things happen?
>>
>> 1) some vDPA device driver probe the hardware and call 
>> vdpa_request_irq() in its PCI probe function.
>> 2) vDPA device is probed by vhost-vDPA
>>
>> Then irq bypass can't work since we when vdpa_unsetup_irq() is 
>> called, there's no driver bound. Or is there a requirement that 
>> vdap_request/free_irq() must be called somewhere (e.g in the 
>> set_status bus operations)? If yes, we need document those requirements.
> vdpa_unseup_irq is only called when we want to unregister the producer,


Typo, I meant vdpa_setup_irq().

Thanks


>   now we have two code path using it: free_irq and relaase(). I agree we can document this requirements for the helpers, these functions can only be called through status changes(DRIVER_OK and !DRIVER_OK).
>
> Thanks,
> BR
> Zhu Lingshan
>>
>> Thanks
>>


  parent reply	other threads:[~2020-07-21  2:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 11:23 [PATCH V2 0/6] IRQ offloading for vDPA Zhu Lingshan
2020-07-16 11:23 ` [PATCH V2 1/6] vhost: introduce vhost_call_ctx Zhu Lingshan
2020-07-17  3:32   ` Jason Wang
2020-07-20  7:40     ` Zhu, Lingshan
2020-07-16 11:23 ` [PATCH V2 2/6] kvm: detect assigned device via irqbypass manager Zhu Lingshan
2020-07-17  4:01   ` Jason Wang
2020-07-20  7:40     ` Zhu, Lingshan
2020-07-17 18:08   ` Alex Williamson
2020-07-20  4:19     ` Jason Wang
2020-07-16 11:23 ` [PATCH V2 3/6] vDPA: implement IRQ offloading helpers in vDPA core Zhu Lingshan
2020-07-17  4:19   ` Jason Wang
     [not found]     ` <45b2cc93-6ae1-47c7-aae6-01afdab1094b@intel.com>
2020-07-20  9:40       ` Jason Wang
     [not found]         ` <8c9adead-d3a0-374e-e817-3cb5a44c4bda@intel.com>
2020-07-21  2:51           ` Jason Wang [this message]
2020-07-16 11:23 ` [PATCH V2 4/6] vhost_vdpa: implement IRQ offloading in vhost_vdpa Zhu Lingshan
2020-07-17  5:29   ` Jason Wang
2020-07-17 10:07   ` kernel test robot
2020-07-17 10:07     ` kernel test robot
2020-07-17 10:07     ` kernel test robot
2020-07-16 11:23 ` [PATCH V2 5/6] ifcvf: replace irq_request/free with vDPA helpers Zhu Lingshan
2020-07-17  5:32   ` Jason Wang
2020-07-16 11:23 ` [PATCH V2 6/6] irqbypass: do not start cons/prod when failed connect Zhu Lingshan

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=8d12231e-aabe-317e-0afb-d680b866304b@redhat.com \
    --to=jasowang@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lingshan.zhu@intel.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wanpengli@tencent.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.