2015-03-06 08:20, Stephen Hemminger:
> The issue is that virtio has no place it can do iopl() and have the IRQ thread
> work. It only shows up on real code where application is daemon, not in a toy
> demo or test application.
>
> Right now:
> gcc start
> rte_virtio_pmd_init
> iopl
> main
> daemon
> fork
> fork
> Process is now child of init not original process
>
> rte_eal_init
> fork (pthread) for irq thread
> irq thread
> (no iopl permssion)
> program start
> rte_pmd_virtio_configure
This call tree is wrong.
Below is the right (and more complete) one:
gcc start
driver constructor
rte_eal_driver_register (if .a)
main
rte_eal_init
eal_parse_args
rte_eal_pci_init
rte_eal_memory_init
rte_eal_intr_init
pthread_create
eal_intr_thread_main
eal_intr_handle_interrupts
eal_intr_process_interrupts
virtio_interrupt_handler
dlopen (if .so)
driver constructor
rte_eal_driver_register
rte_eal_dev_init
driver->init
rte_virtio_pmd_init
rte_eal_iopl_init
rte_eth_driver_register
pthread_create
rte_eal_pci_probe
driver->devinit
rte_eth_dev_init
rte_eth_dev_allocate
eth_drv->eth_dev_init
eth_virtio_dev_init
virtio_resource_init
> So the only place where iopl() can be done in the proper context
> so that the IRQ (and other helper threads in future) have the correct
> permissions is in eal_init.
No there are 2 other possible solutions:
1) Move rte_eal_intr_init() after rte_eal_dev_init().
2) Move dlopen() before rte_eal_intr_init() and call iopl in the constructor.
With the second solution, we must also keep an iopl call in
rte_virtio_pmd_init()
to return an error if iopl fails.
The second solution was proposed in the series sent by David:
http://dpdk.org/ml/archives/dev/2015-March/014931.html
http://dpdk.org/ml/archives/dev/2015-March/014932.html
