Zhu Lingshan
2021-Apr-15 06:36 UTC
[PATCH 1/3] vDPA/ifcvf: deduce VIRTIO device ID when probe
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 at 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. > > ThanksYes, 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; >>> >> >
Jason Wang
2021-Apr-15 07:16 UTC
[PATCH 1/3] vDPA/ifcvf: deduce VIRTIO device ID when probe
? 2021/4/15 ??2:36, Zhu Lingshan ??:> > > 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 at 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. > > ThanksOk, so I think it's better to add a comment here. 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; >>>> >>> >> >