Re: Update virtio network driver

[Pavel Pisa]

Hello Jin-Hyun,

On Tuesday 15 of November 2016 11:29:05 Pavel Pisa wrote:
> Hello Jin-Hyun,
>
> thanks for update.
>
> I have returned from my USA holydays now and catching up
> with e-mails and work backlogs.
>
> On Thursday 10 of November 2016 10:42:34 Jinhyun 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, 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.
>
> I have done some updates and testing of your work some time ago.
> I think I reported that but I am not 100% sure. Please,
> look if some changes in my WIP branch are of some use for you

OK, I see that it is integrated.

Great.

Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Update virtio network driver

[Pavel Pisa]

Hello Jin-Hyun,

thanks for update.

I have returned from my USA holydays now and catching up
with e-mails and work backlogs.

On Thursday 10 of November 2016 10:42:34 Jinhyun 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,
> 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.

I have done some updates and testing of your work some time ago.
I think I reported that but I am not 100% sure. Please,
look if some changes in my WIP branch are of some use for you

https://github.com/ppisa/rtems/commits/devel-virtio

As for RTEMS_COMPILER_MEMORY_BARRIER() suggested by Gedare,
I am not sure if it is enough in some places.
VirtIO is PCI like device and compiler barrier would
work if the hypervisor places data into shared
buffer from the same CPU. If it runs on different
one in parallel with RTEMS driver (in network polled API
like mode) then real SMP barrier is more appropriate.

Best wishes,

Pavel

> 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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: 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: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of Gedare 
Bloom
Sent: Friday, November 11, 2016 3:27 AM
To: Jinhyun <jinh...@konkuk.ac.kr>
Cc: devel@rtems.org; j...@konkuk.ac.kr
Subject: Re: Update virtio network driver


On Thu, Nov 10, 2016 at 4:42 AM, Jinhyun <jinh...@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Update virtio network driver

[Gedare Bloom]

On Thu, Nov 10, 2016 at 4:42 AM, Jinhyun  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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Update virtio network driver

[Jinhyun]

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,
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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel