On 2021/1/28 0:45, Ferruh Yigit wrote:

On 1/27/2021 2:43 PM, 谢华伟(此时此刻） wrote:

quoted

On 2021/1/27 18:32, Ferruh Yigit wrote:

quoted

I was waiting for clarification if this can be solved in virtio, 
which seems clarified and decided to go with this patch, I am OK to 
proceed with patch 1 & 2.

But first patch changes how PIO address get, it changes the Linux 
interface used to get the PIO.
And as far as I can see second patch requires this new interface to 
be able to access the MEM resources.

I have a concern that this interface change may cause issues with 
various distros, kernel versions etc.. And prefer it goes through a 
full -rc1 validation cycle.

Huawei, I am aware the patch is around for a while but to play safe, 
I suggest considering it for early next release, so it can be tested 
enough, instead of getting if for -rc2/3 in this release.

Thanks,
ferruh

Hi Ferruh and Maxime:

igb_uio kernel driver gets resource through pci_resource_start, i.e, 
(dev)->resource[(bar)].start

uio_pci_generic and the generic way in my patch 1 gets resource 
through the same interface:

         pci dev driver exports to userspace the bar resource 
attributes through pci_dev->resource (check resource_show in kernel's 
drivers/pci/pci-sysfs.c)

Other arch than x86 uses the same interface in their pci_uio_ioport_map.

So patch 1 is the most generic way and shouldn't break things. 
/proc/ioports should be fully dropped.

Using /proc/ioport is partly my fault at the very beginning. It 
causes so much mess.

Could you please confirm this?

Hi Huawei,

I confirm that interface is already in use, 
'pci_parse_sysfs_resource()' does similar parsing.

Most probably it is safe as you and Maxime said, and I am not trying 
to be difficult but extra conscious here.

Will it cause too much trouble to consider the patch early next 
release? This gives more time and testing after the patch merged.

Thanks,
ferruh

Hi Ferruh:

If early next release, what is about the schedule, early next February?


In summary, patch 1 is simple and straightforward. It just don't use 
/proc/ioports and don't use resource attribute created by igb_uio and 
use the standard resource attribute under /sys/pci/.

As i explained, the resource attribute created by igb_uio is exactly the 
same thing as the standard resource attribute under /sys/pci/.

Patch 1 fixes messy things. Patch 2 fixes wrong assumptions (BAR is IO bar).


Customers have been pushing us for quite a long time. Besides, at least 
in China,  virtio in VM with MMIO bar is a de-facto implementation. It 
brings quite much trouble not only to cloud users, but also to us self 
when we run DPDK.

quoted

Thanks huawei

quoted

quoted

Could you please post v6?

Thanks,
Maxime

quoted

quoted

It is not too late for this release, as the change will not be that
intrusive. But if you prepare such patch, please base it on top 
of my
virtio rework series; To make it easier to you, I added it to the 
dpdk-
next-virtio tree:
https://git.dpdk.org/next/dpdk-next-virtio/log/?h=virtio_pmd_rework_v2 


Thanks,
Maxime