Hello Jin-Hyun Kim, Hyun-Wook Jin and others, I have returned back to VirtIO based network driver after I have make PCI based E100 card work by woraround which re-enables IRQ in driver worker daemon.
In meanwhile, I have included alternative networking setup with E100 to RTEMS QEMU Wiki page https://devel.rtems.org/wiki/Developer/Simulators/QEMU#Inteli82557be100PCICardEmulation I have cleaned a VirtIO driver a little but including IRQ workaround would be really complicated in this case. Interrupt source signalling is cleaned by inport_byte from corresponding VIRTIO_PCI_ISR. But if interrupt is disabled on controller level by i8259 then reenable would to be moved to rtems_bsdnet worker thread. But that would violate all ideas about separation of layers and encapsulation. Not by one, but over three levels. So I have corrected (at least according my feeling) i8259 IRQ processing. The VirtIO networking seems to work great with this fix. There is updated VirtIO support on branch "devel-virtio" of my GitHub repository https://github.com/ppisa/rtems/tree/devel-virtio I would like express big thanks to authors that they have contributed port. The last time there has not been reached final decision if the code should be included in RTEMS or if there is plug on old networking stack. I think that it works well and can be used before there is other alternative location for the code. As for the code, I would be happy if it can be moved out of i386 BSP directory or at least that part which is independent if there is some i386 specific code. But it uses generic IRQ now, generic PCI so it should be usable with all other architectures. There is even another reason why to included virtio support. It can be used (if extended) even for providing disk device to the virtualized environment and this part probably stays in core RTEMS codebase even if libbsd is used for networking. Best wishes, Pavel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel