All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhu Lingshan <lingshan.zhu@linux.intel.com>
To: Jason Wang <jasowang@redhat.com>,
	Zhu Lingshan <lingshan.zhu@intel.com>,
	mst@redhat.com, lulu@redhat.com, leonro@nvidia.com
Cc: virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] vDPA/ifcvf: deduce VIRTIO device ID when probe
Date: Thu, 15 Apr 2021 14:36:15 +0800	[thread overview]
Message-ID: <92ef6264-4462-cbd4-5db8-6ce6b68762e0@linux.intel.com> (raw)
In-Reply-To: <ffd2861d-2395-de51-a227-f1ef33f74322@redhat.com>



On 4/15/2021 2:30 PM, Jason Wang wrote:
>
> 在 2021/4/15 下午1:52, Zhu Lingshan 写道:
>>
>>
>> On 4/15/2021 11:30 AM, Jason Wang wrote:
>>>
>>> 在 2021/4/14 下午5:18, Zhu Lingshan 写道:
>>>> This commit deduces VIRTIO device ID as device type when probe,
>>>> then ifcvf_vdpa_get_device_id() can simply return the ID.
>>>> ifcvf_vdpa_get_features() and ifcvf_vdpa_get_config_size()
>>>> can work properly based on the device ID.
>>>>
>>>> Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
>>>> ---
>>>>   drivers/vdpa/ifcvf/ifcvf_base.h |  1 +
>>>>   drivers/vdpa/ifcvf/ifcvf_main.c | 22 ++++++++++------------
>>>>   2 files changed, 11 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h 
>>>> b/drivers/vdpa/ifcvf/ifcvf_base.h
>>>> index b2eeb16b9c2c..1c04cd256fa7 100644
>>>> --- a/drivers/vdpa/ifcvf/ifcvf_base.h
>>>> +++ b/drivers/vdpa/ifcvf/ifcvf_base.h
>>>> @@ -84,6 +84,7 @@ struct ifcvf_hw {
>>>>       u32 notify_off_multiplier;
>>>>       u64 req_features;
>>>>       u64 hw_features;
>>>> +    u32 dev_type;
>>>>       struct virtio_pci_common_cfg __iomem *common_cfg;
>>>>       void __iomem *net_cfg;
>>>>       struct vring_info vring[IFCVF_MAX_QUEUE_PAIRS * 2];
>>>> diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c 
>>>> b/drivers/vdpa/ifcvf/ifcvf_main.c
>>>> index 44d7586019da..99b0a6b4c227 100644
>>>> --- a/drivers/vdpa/ifcvf/ifcvf_main.c
>>>> +++ b/drivers/vdpa/ifcvf/ifcvf_main.c
>>>> @@ -323,19 +323,9 @@ static u32 ifcvf_vdpa_get_generation(struct 
>>>> vdpa_device *vdpa_dev)
>>>>     static u32 ifcvf_vdpa_get_device_id(struct vdpa_device *vdpa_dev)
>>>>   {
>>>> -    struct ifcvf_adapter *adapter = vdpa_to_adapter(vdpa_dev);
>>>> -    struct pci_dev *pdev = adapter->pdev;
>>>> -    u32 ret = -ENODEV;
>>>> -
>>>> -    if (pdev->device < 0x1000 || pdev->device > 0x107f)
>>>> -        return ret;
>>>> -
>>>> -    if (pdev->device < 0x1040)
>>>> -        ret =  pdev->subsystem_device;
>>>> -    else
>>>> -        ret =  pdev->device -0x1040;
>>>> +    struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
>>>>   -    return ret;
>>>> +    return vf->dev_type;
>>>>   }
>>>>     static u32 ifcvf_vdpa_get_vendor_id(struct vdpa_device *vdpa_dev)
>>>> @@ -466,6 +456,14 @@ static int ifcvf_probe(struct pci_dev *pdev, 
>>>> const struct pci_device_id *id)
>>>>       pci_set_drvdata(pdev, adapter);
>>>>         vf = &adapter->vf;
>>>> +    if (pdev->device < 0x1000 || pdev->device > 0x107f)
>>>> +        return -EOPNOTSUPP;
>>>> +
>>>> +    if (pdev->device < 0x1040)
>>>> +        vf->dev_type =  pdev->subsystem_device;
>>>> +    else
>>>> +        vf->dev_type =  pdev->device - 0x1040;
>>>
>>>
>>> So a question here, is the device a transtional device or modern one?
>>>
>>> If it's a transitonal one, can it swtich endianess automatically or 
>>> not?
>>>
>>> Thanks
>> Hi Jason,
>>
>> This driver should drive both modern and transitional devices as we 
>> discussed before.
>> If it's a transitional one, it will act as a modern device by 
>> default, legacy mode is a fail-over path.
>
>
> Note that legacy driver use native endian, support legacy driver 
> requires the device to know native endian which I'm not sure your 
> device can do that.
>
> Thanks
Yes, legacy requires guest native endianess, I think we don't need to 
worry about this because our transitional device should work in modern 
mode by
default(legacy mode is the failover path we will never reach, 
get_features will fail if no ACCESS_PLATFORM), we don't support legacy 
device in vDPA.

Thanks
>
>
>> For vDPA, it has to support VIRTIO_1 and ACCESS_PLATFORM, so it must 
>> in modern mode.
>> I think we don't need to worry about endianess for legacy mode.
>>
>> Thanks
>> Zhu Lingshan
>>>
>>>
>>>> +
>>>>       vf->base = pcim_iomap_table(pdev);
>>>>         adapter->pdev = pdev;
>>>
>>
>


WARNING: multiple messages have this Message-ID (diff)
From: Zhu Lingshan <lingshan.zhu@linux.intel.com>
To: Jason Wang <jasowang@redhat.com>,
	Zhu Lingshan <lingshan.zhu@intel.com>,
	mst@redhat.com, lulu@redhat.com, leonro@nvidia.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 1/3] vDPA/ifcvf: deduce VIRTIO device ID when probe
Date: Thu, 15 Apr 2021 14:36:15 +0800	[thread overview]
Message-ID: <92ef6264-4462-cbd4-5db8-6ce6b68762e0@linux.intel.com> (raw)
In-Reply-To: <ffd2861d-2395-de51-a227-f1ef33f74322@redhat.com>



On 4/15/2021 2:30 PM, Jason Wang wrote:
>
> 在 2021/4/15 下午1:52, Zhu Lingshan 写道:
>>
>>
>> On 4/15/2021 11:30 AM, Jason Wang wrote:
>>>
>>> 在 2021/4/14 下午5:18, Zhu Lingshan 写道:
>>>> This commit deduces VIRTIO device ID as device type when probe,
>>>> then ifcvf_vdpa_get_device_id() can simply return the ID.
>>>> ifcvf_vdpa_get_features() and ifcvf_vdpa_get_config_size()
>>>> can work properly based on the device ID.
>>>>
>>>> Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
>>>> ---
>>>>   drivers/vdpa/ifcvf/ifcvf_base.h |  1 +
>>>>   drivers/vdpa/ifcvf/ifcvf_main.c | 22 ++++++++++------------
>>>>   2 files changed, 11 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h 
>>>> b/drivers/vdpa/ifcvf/ifcvf_base.h
>>>> index b2eeb16b9c2c..1c04cd256fa7 100644
>>>> --- a/drivers/vdpa/ifcvf/ifcvf_base.h
>>>> +++ b/drivers/vdpa/ifcvf/ifcvf_base.h
>>>> @@ -84,6 +84,7 @@ struct ifcvf_hw {
>>>>       u32 notify_off_multiplier;
>>>>       u64 req_features;
>>>>       u64 hw_features;
>>>> +    u32 dev_type;
>>>>       struct virtio_pci_common_cfg __iomem *common_cfg;
>>>>       void __iomem *net_cfg;
>>>>       struct vring_info vring[IFCVF_MAX_QUEUE_PAIRS * 2];
>>>> diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c 
>>>> b/drivers/vdpa/ifcvf/ifcvf_main.c
>>>> index 44d7586019da..99b0a6b4c227 100644
>>>> --- a/drivers/vdpa/ifcvf/ifcvf_main.c
>>>> +++ b/drivers/vdpa/ifcvf/ifcvf_main.c
>>>> @@ -323,19 +323,9 @@ static u32 ifcvf_vdpa_get_generation(struct 
>>>> vdpa_device *vdpa_dev)
>>>>     static u32 ifcvf_vdpa_get_device_id(struct vdpa_device *vdpa_dev)
>>>>   {
>>>> -    struct ifcvf_adapter *adapter = vdpa_to_adapter(vdpa_dev);
>>>> -    struct pci_dev *pdev = adapter->pdev;
>>>> -    u32 ret = -ENODEV;
>>>> -
>>>> -    if (pdev->device < 0x1000 || pdev->device > 0x107f)
>>>> -        return ret;
>>>> -
>>>> -    if (pdev->device < 0x1040)
>>>> -        ret =  pdev->subsystem_device;
>>>> -    else
>>>> -        ret =  pdev->device -0x1040;
>>>> +    struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
>>>>   -    return ret;
>>>> +    return vf->dev_type;
>>>>   }
>>>>     static u32 ifcvf_vdpa_get_vendor_id(struct vdpa_device *vdpa_dev)
>>>> @@ -466,6 +456,14 @@ static int ifcvf_probe(struct pci_dev *pdev, 
>>>> const struct pci_device_id *id)
>>>>       pci_set_drvdata(pdev, adapter);
>>>>         vf = &adapter->vf;
>>>> +    if (pdev->device < 0x1000 || pdev->device > 0x107f)
>>>> +        return -EOPNOTSUPP;
>>>> +
>>>> +    if (pdev->device < 0x1040)
>>>> +        vf->dev_type =  pdev->subsystem_device;
>>>> +    else
>>>> +        vf->dev_type =  pdev->device - 0x1040;
>>>
>>>
>>> So a question here, is the device a transtional device or modern one?
>>>
>>> If it's a transitonal one, can it swtich endianess automatically or 
>>> not?
>>>
>>> Thanks
>> Hi Jason,
>>
>> This driver should drive both modern and transitional devices as we 
>> discussed before.
>> If it's a transitional one, it will act as a modern device by 
>> default, legacy mode is a fail-over path.
>
>
> Note that legacy driver use native endian, support legacy driver 
> requires the device to know native endian which I'm not sure your 
> device can do that.
>
> Thanks
Yes, legacy requires guest native endianess, I think we don't need to 
worry about this because our transitional device should work in modern 
mode by
default(legacy mode is the failover path we will never reach, 
get_features will fail if no ACCESS_PLATFORM), we don't support legacy 
device in vDPA.

Thanks
>
>
>> For vDPA, it has to support VIRTIO_1 and ACCESS_PLATFORM, so it must 
>> in modern mode.
>> I think we don't need to worry about endianess for legacy mode.
>>
>> Thanks
>> Zhu Lingshan
>>>
>>>
>>>> +
>>>>       vf->base = pcim_iomap_table(pdev);
>>>>         adapter->pdev = pdev;
>>>
>>
>

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-04-15  6:36 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14  9:18 [PATCH 0/3] vDPA/ifcvf: enables Intel C5000X-PL virtio-blk Zhu Lingshan
2021-04-14  9:18 ` [PATCH 1/3] vDPA/ifcvf: deduce VIRTIO device ID when probe Zhu Lingshan
2021-04-15  3:30   ` Jason Wang
2021-04-15  3:30     ` Jason Wang
2021-04-15  5:52     ` Zhu Lingshan
2021-04-15  5:52       ` Zhu Lingshan
2021-04-15  6:30       ` Jason Wang
2021-04-15  6:30         ` Jason Wang
2021-04-15  6:36         ` Zhu Lingshan [this message]
2021-04-15  6:36           ` Zhu Lingshan
2021-04-15  7:16           ` Jason Wang
2021-04-15  7:16             ` Jason Wang
2021-04-15  7:23             ` Zhu Lingshan
2021-04-15  7:23               ` Zhu Lingshan
2021-04-14  9:18 ` [PATCH 2/3] vDPA/ifcvf: enable Intel C5000X-PL virtio-block for vDPA Zhu Lingshan
2021-04-15  3:34   ` Jason Wang
2021-04-15  3:34     ` Jason Wang
2021-04-15  5:55     ` Zhu Lingshan
2021-04-15  5:55       ` Zhu Lingshan
2021-04-15  6:31       ` Jason Wang
2021-04-15  6:31         ` Jason Wang
2021-04-15  6:41         ` Zhu Lingshan
2021-04-15  6:41           ` Zhu Lingshan
2021-04-15  7:17           ` Jason Wang
2021-04-15  7:17             ` Jason Wang
2021-04-15  7:23             ` Zhu Lingshan
2021-04-15  7:23               ` Zhu Lingshan
2021-04-14  9:18 ` [PATCH 3/3] vDPA/ifcvf: get_config_size should return dev specific config size Zhu Lingshan
2021-04-15  3:36   ` Jason Wang
2021-04-15  3:36     ` Jason Wang
2021-04-15  8:12   ` Stefano Garzarella
2021-04-15  8:12     ` Stefano Garzarella
2021-04-15  8:16     ` Jason Wang
2021-04-15  8:16       ` Jason Wang
2021-04-15  8:23     ` Zhu Lingshan
2021-04-15  8:33       ` Stefano Garzarella

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=92ef6264-4462-cbd4-5db8-6ce6b68762e0@linux.intel.com \
    --to=lingshan.zhu@linux.intel.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=leonro@nvidia.com \
    --cc=lingshan.zhu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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.