[dpdk-dev] [PATCH v7 2/2] bus/pci: support MMIO in PCI ioport accessors
ferruh.yigit at intel.com
Wed Feb 24 16:45:11 CET 2021
On 2/23/2021 2:20 PM, 谢华伟(此时此刻） wrote:
> On 2021/2/23 1:25, Ferruh Yigit wrote:
>> On 2/22/2021 5:15 PM, 谢华伟(此时此刻） wrote:
>>> From: "huawei.xhw" <huawei.xhw at alibaba-inc.com>
>>> With IO BAR, we get PIO(programmed IO) address.
>>> With MMIO BAR, we get mapped virtual address.
>>> We distinguish PIO(Programmed IO) and MMIO(memory mapped IO) by their address
>>> like how kernel does.
>>> ioread/write8/16/32 is provided to access PIO/MMIO.
>>> By the way, for virtio on arch other than x86, BAR flag indicates PIO but is
>>> Signed-off-by: huawei xie <huawei.xhw at alibaba-inc.com>
>>> Reviewed-by: Maxime Coquelin <maxime.coquelin at redhat.com>
>>> +static inline void iowrite8(uint8_t val, void *addr)
>>> + (uint64_t)(uintptr_t)addr >= PIO_MAX ?
>>> + *(volatile uint8_t *)addr = val :
>>> + outb(val, (unsigned long)addr);
>> //copying question from previous version:
>> Is the 'outb_p' to 'outb' conversion intentional? And if so why?
>> Same of the all 'outb_p', 'outw_p', 'outl_p'.
> There is no need to delay for virtio device, as we can see in virtio legacy driver.
> IMO, the delay is for ugly old device. The device itself should assure the
> previous IO completes when the subsequent IO instruction arrives.
Can there be any virtio legacy device needing this?
What is the downside of using "pause until the I/O completes" versions?
More information about the dev