On 1/22/21 8:25 AM, 谢华伟(此时此刻） wrote:

On 2021/1/21 23:38, Maxime Coquelin wrote:

quoted

quoted

Do you mean we apply or abandon patch 3? I am both OK. The first
priority to me is to enable MMIO bar support.

OK, so yes, I think we should abandon patch 2 and patch 3.
For patch 1, it looks valid to me, but I'll let Ferruh decide.

For your device, if my understanding is correct, what we need to do is
to support MMIO for legacy devices. Correct?

yes.

quoted

If so, the change should be in virtio_pci.c. In vtpci_init(), after
modern detection has failed, we should check the the BAR is PIO or MMIO
based on the flag. the result can be saved in struct virtio_pci_dev.


We would introduce new wrappers like vtpci_legacy_read,
vtpci_legacy_write that would either call rte_pci_ioport_read,
rte_pci_ioport_read in case of PIO, or rte_read32, rte_write32 in case
of MMIO.

There are two choices.

1, apply patch 2.

    IO/MMIO port are mapped and accessed using the same API. Kernel is
doing in the same way like the following.

            io_addr = pci_iomap

                get PIO directly or ioremap

            iowrite16/32(val, io_addr + offset)

I think applying patch 2 is a correct choice. It is a fix. Driver had
better not know if bar is PIO or MMIO.  ioport in ioport_xx API means
IO, not PIO.

Btw, it only affects virtio PMD,  not that intrusive.

 2, virtio specific change to enable MMIO support.

Comparing with choice 1, i feels it is not that clean and pretty.

OK, that makes sense. I am OK with keeping patch 2, but would like
Ferruh's ACK.

Could you please post v6?

Thanks,
Maxime

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