Update virtio network driver

[Jinhyun]

We use __sync_synchronize() to generate hardware memory barrier same as mb() of FreeBSD does.
And we know that RTEMS_COMPILER_MEMORY_BARRIER() generates compiler memory barrier not hardware memory barrier, doesn't it?

On PowerPC, it seems that RTEMS_COMPILER_MEMORY_BARRIER() is replaced by __asm__ volatile("":::"memory").
But mb() of FreeBSD is replaced by __asm__ volatile("sync":::"memory").
And __sync_synchronize() generates assembly code "sync".
So we use __sync_synchronize() to replace mb() of FreeBSD.

However the driver also works well when we use RTEMS_COMPILER_MEMORY_BARRIER() because the driver almost works well without any barrier, too.

-----Original Message-----
From: gedare at gwmail.gwu.edu [mailto:gedare at gwmail.gwu.edu] On Behalf Of Gedare Bloom
Sent: Friday, November 11, 2016 3:27 AM
To: Jinhyun <jinhyun at konkuk.ac.kr>
Cc: devel at rtems.org; jinh at konkuk.ac.kr
Subject: Re: Update virtio network driver


On Thu, Nov 10, 2016 at 4:42 AM, Jinhyun <jinhyun at konkuk.ac.kr> wrote:
> Hi, all!
>
> We removed our RTEMS-virtio driver's dependencies on architecture. We 
> used built-in function of gcc, __sync_synchronize(). This function 
> generates proper memory barrier for target architecture on compile 
> time. In addition,
Would RTEMS_COMPILER_MEMORY_BARRIER() work for you?

> we replaced pcib_conf_read/write functions to pci_read/write_config 
> functions. We added several lines of codes for exception handling 
> suggested by Pavel Pisa. Thank you, Pavel Pisa. As we removed 
> dependencies on CPU architectures, we moved the virtio source 
> directory located at c/src/lib/libbsp/i386/pc386/ to c/src/lib/libbsp/shared.
>
> We plan to enhance the virtio driver for RTEMS, and we have several 
> additional patches for it. To easily manage this project from our 
> side, we created Github repository. You can see the latest version of 
> our virtio driver in our Github: 
> https://github.com/sslab-konkuk/RTEMS-virtio
>
> Recently, we succeeded to test the virtio with Motorola_powerpc BSP. 
> For this, we made additional modifications. Motorola_powerpc BSP 
> doesn't support functions such as rtems_insterrupt_handler_install, so 
> we used functions such as BSP_install_rtems_irq_handler instead of 
> those. Moreover, in order to make our virtio work on PowerPC, we added 
> initialization codes to virtio_pci.c because qemu_fakerom, which is 
> the PowerPC bios of Motorola_powerpc BSP, doesn't initialize the 
> virtio back-end driver. But some runtime error is occurred on RTEMS 
> master branch, so we will submit about it again soon.
>
> Best regards,
> Jin-Hyun.
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel