A virtio front-end driver for RTEMS
Hi, I am a graduate student of System Software Lab at Konkuk University (http://sslab.konkuk.ac.kr). We are implementing a virtio front-end network driver for RTEMS and have published some preliminary results in ACM SIGBED Review (http://sigbed.seas. upenn.edu/archives/2016-01/EWiLi15_5.pdf). The current version of our implementation runs quite stably with RTEMS-pc386 over KVM hypervisor (linux 3.18.0). Now we are trying to make it work over VirtualBox. If the RTEMS community is interested in our work, wed like to open the source codes and contribute to RTEMS. However, currently, we are not sure whether our virtio driver is better to be incorporated in an RTEMS source branch or to be managed separately through our own GitHub for example. Please give your advice. with best regards, Jin-Hyun ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: A virtio front-end driver for RTEMS
Thank you for the comment. We got little bit delayed to meet the RTEMS coding standard. Regarding the source commitment, we have following questions. 1. Shall we just post diffs to the mailing list? (FYI, our implementation includes about 10 files and 1,300~1,500 lines total) 2. Will it be ok if we generate a directory ‘virtio’ under the ‘pc386’ directory? (i.e., … libbsp/i386/pc386/virtio) Thanks, Jin-Hyun -Original Message- From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of Gedare Bloom Sent: Friday, March 11, 2016 2:14 AM To: Jinhyun Cc: rtems-de...@rtems.org ; j...@konkuk.ac.kr Subject: Re: A virtio front-end driver for RTEMS I'm glad to hear this. The path of least resistance would be to merge the driver into the pc386 BSP on rtems.git. That bsp tree is currently undergoing a lot of activity, but once you get your driver merged I would imagine it is not too hard to maintain. It would also be of interest to get instructions for using RTEMS-pc386 on KVM added to the RTEMS wiki. By merging the driver into RTEMS it will be more easily shared and can be community-maintained especially if we can eventually get the KVM version included in our planned continuous integration efforts. Gedare On Tue, Mar 8, 2016 at 5:43 AM, Jinhyun wrote: > Hi, > I am a graduate student of System Software Lab at Konkuk University > (http://sslab.konkuk.ac.kr). > We are implementing a virtio front-end network driver for RTEMS and > have published some preliminary results in ACM SIGBED Review > (http://sigbed.seas. > upenn.edu/archives/2016-01/EWiLi15_5.pdf). > The current version of our implementation runs quite stably with > RTEMS-pc386 over KVM hypervisor (linux 3.18.0). > Now we are trying to make it work over VirtualBox. > > If the RTEMS community is interested in our work, we’d like to open > the source codes and contribute to RTEMS. However, currently, we are > not sure whether our virtio driver is better to be incorporated in an > RTEMS source branch or to be managed separately through our own GitHub > for example. Please give your advice. > > with 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
[PATCH] pc386: Add virtio network driver
diff --git a/c/src/lib/libbsp/i386/pc386/Makefile.am
b/c/src/lib/libbsp/i386/pc386/Makefile.am
index d9af7dd..da50c67 100644
--- a/c/src/lib/libbsp/i386/pc386/Makefile.am
+++ b/c/src/lib/libbsp/i386/pc386/Makefile.am
@@ -232,6 +232,19 @@ noinst_PROGRAMS += 3c509.rel
3c509_rel_LDFLAGS += -Wl,--undefined=ep_board
endif
+if HAS_NETWORKING
+vtnet_CPPFLAGS = -D__INSIDE_RTEMS_BSD_TCPIP_STACK__
+noinst_PROGRAMS += vtnet.rel
+vtnet_rel_SOURCES = virtio/if_vtnet.c
+vtnet_rel_SOURCES += virtio/if_vtnet.h
+vtnet_rel_SOURCES += virtio/virtio_pci.c
+vtnet_rel_SOURCES += virtio/virtio_pci.h
+vtnet_rel_SOURCES += virtio/virtio.c
+vtnet_rel_SOURCES += virtio/virtio.h
+vtnet_rel_CPPFLAGS = $(AM_CPPFLAGS) $(vtnet_CPPFLAGS)
+vtnet_rel_LDFLAGS = $(RTEMS_RELLDFLAGS)
+endif
+
libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/cache.rel
libbsp_a_LIBADD += ../../../libcpu/@RTEMS_CPU@/page.rel
libbsp_a_LIBADD += ../../../libcpu/@RTEMS_CPU@/score.rel
@@ -246,6 +259,7 @@ if HAS_NETWORKING
libbsp_a_LIBADD += ne2000.rel
libbsp_a_LIBADD += wd8003.rel
libbsp_a_LIBADD += 3c509.rel
+libbsp_a_LIBADD += vtnet.rel
endif
EXTRA_DIST += HOWTO
diff --git a/c/src/lib/libbsp/i386/pc386/virtio/if_vtnet.c
b/c/src/lib/libbsp/i386/pc386/virtio/if_vtnet.c
new file mode 100644
index 000..4fcd92c
--- /dev/null
+++ b/c/src/lib/libbsp/i386/pc386/virtio/if_vtnet.c
@@ -0,0 +1,1032 @@
+/**
+ * @file if_vtnet.c
+ * @brief Driver for virtio network devices
+ */
+
+/*
+ * Copyright (c) 2016 Jin-Hyun Kim
+ * and Hyun-Wook Jin
+ * Ported from FreeBSD to RTEMS March 16, http://sslab.konkuk.ac.kr
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+/*-
+ * Copyright (c) 2011, Bryan Venteicher
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice unmodified, this list of conditions, and the following
+ *disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include
+
+#include "virtio.h"
+#include "virtio_pci.h"
+#include "if_vtnet.h"
+
+static struct vtnet_softc vtnet_softc;
+static rtems_interval vtnet_ticksPerSecond;
+
+int rtems_vtnet_driver_attach(
+ struct rtems_bsdnet_ifconfig *config,
+ int attaching
+)
+{
+ struct vtnet_softc *sc;
+ int ret;
+
+ printk( "rtems_vtnet_driver_attach start\n" );
+
+ sc = &vtnet_softc;
+ memset( sc, 0, sizeof( struct vtnet_softc ) );
+
+ /* Set up timing values */
+ vtnet_ticksPerSecond = rtems_clock_get_ticks_per_second();
+
+ printk( "\tAttaching virtio pci...\n" );
+ ret = vtpci_attach( config, &sc->vtpci_softc );
+
+ if ( ret ) {
+printk( "vtpci_attach fail...\n" );
+ }
+
+ /* Alloc virtqueues */
+ printk( "\tAllocating virtqueues...\n" );
+ ret = vtnet_alloc_virtqueues( sc );
+
+ if ( ret ) {
+printk( "vtnet_alloc_virtqueues fail...\n" );
+ }
+
+ /* Setup interrupt */
+ printk( "\tSetup interrupt...\n" );
+ ret = vtnet_setup_intr( &sc->vtpci_softc );
+
+ if ( ret ) {
+printk( "vtpci_setup_intr fail...\n" );
+ }
+
+ /* Setup interface */
+ printk( "\tSetup interface...\n" );
+ ret = vtnet_setup_interface( sc, config );
+
+ if ( ret ) {
+printk( "vtnet_setup_interface fail...\n" );
+ }
+
+ printk( "rtems_vtnet_driver_attach end\n" );
+
+ return 0;
+}
+
+static int vtnet_alloc_virtqueues( struct vtnet_softc *sc )
+{
+ uint16_t val16;
+ int size, error;
+
+ /* Init virtio_net_hdr */
+ memset( &sc->vtnet_net_hdr, 0, sizeof( struct virtio_net_hdr ) );
+
+ /* Select virtqueue 0 */
+ vtpci_io_write_2( &sc->vtpci_softc,
+VIRTIO_PCI_QUEUE_SEL,
+VIRTIO_PCI_QUEUE_SEL_RX );
+ val16 = vtpci_io_read_2( &sc->vtpci_softc
RE: [PATCH] pc386: Add virtio network driver
Thanks for your comments and interest in our patch. Our implementation is based on FreeBSD version release 10.0.0. As you have suggested, we will add ifdefs to distinguish the RTEMS specific codes and resubmit the patch. In addition, we will add instructions on how to use it in virtio/README.txt. Let us know if this is OK. Thanks, Jin-Hyun From: Joel Sherrill [mailto:j...@rtems.org] Sent: Tuesday, March 29, 2016 11:41 PM To: Jinhyun Cc: rtems-de...@rtems.org ; j...@konkuk.ac.kr Subject: Re: [PATCH] pc386: Add virtio network driver Hi Thanks for the submission. My comments are going to be very general. + Can you document which version of the FreeBSD source files this is based up? Perhaps an svn revision/branch and a list of the exact files in their source tree? This has been a historical problem when trying to track future changes. + What were the nature of the rtems specific changes? Are they cleanly ifdef'ed so a diff against the original FreeBSD source shows ifdef additions and blocks of RTEMS specific code added? + I didn't see any instructions on how to use this. What type of setup is needed? I am pretty sure I actually reviewed a conference paper on this work and am excited to see it submitted. Let's just make it top notch on usability and maintainability. --joel On Tue, Mar 29, 2016 at 8:47 AM, Jinhyun <mailto:jinh...@konkuk.ac.kr> wrote: diff --git a/c/src/lib/libbsp/i386/pc386/Makefile.am b/c/src/lib/libbsp/i386/pc386/Makefile.am index d9af7dd..da50c67 100644 --- a/c/src/lib/libbsp/i386/pc386/Makefile.am +++ b/c/src/lib/libbsp/i386/pc386/Makefile.am @@ -232,6 +232,19 @@ noinst_PROGRAMS += 3c509.rel 3c509_rel_LDFLAGS += -Wl,--undefined=ep_board endif +if HAS_NETWORKING +vtnet_CPPFLAGS = -D__INSIDE_RTEMS_BSD_TCPIP_STACK__ +noinst_PROGRAMS += vtnet.rel +vtnet_rel_SOURCES = virtio/if_vtnet.c +vtnet_rel_SOURCES += virtio/if_vtnet.h +vtnet_rel_SOURCES += virtio/virtio_pci.c +vtnet_rel_SOURCES += virtio/virtio_pci.h +vtnet_rel_SOURCES += virtio/virtio.c +vtnet_rel_SOURCES += virtio/virtio.h +vtnet_rel_CPPFLAGS = $(AM_CPPFLAGS) $(vtnet_CPPFLAGS) +vtnet_rel_LDFLAGS = $(RTEMS_RELLDFLAGS) +endif + libbsp_a_LIBADD = mailto:../../../libcpu/@RTEMS_CPU@/cache.rel libbsp_a_LIBADD += mailto:../../../libcpu/@RTEMS_CPU@/page.rel libbsp_a_LIBADD += mailto:../../../libcpu/@RTEMS_CPU@/score.rel @@ -246,6 +259,7 @@ if HAS_NETWORKING libbsp_a_LIBADD += ne2000.rel libbsp_a_LIBADD += wd8003.rel libbsp_a_LIBADD += 3c509.rel +libbsp_a_LIBADD += vtnet.rel endif EXTRA_DIST += HOWTO diff --git a/c/src/lib/libbsp/i386/pc386/virtio/if_vtnet.c b/c/src/lib/libbsp/i386/pc386/virtio/if_vtnet.c new file mode 100644 index 000..4fcd92c --- /dev/null +++ b/c/src/lib/libbsp/i386/pc386/virtio/if_vtnet.c @@ -0,0 +1,1032 @@ +/** + * @file if_vtnet.c + * @brief Driver for virtio network devices + */ + +/* + * Copyright (c) 2016 Jin-Hyun Kim <mailto:jinh...@konkuk.ac.kr> + * and Hyun-Wook Jin <mailto:j...@konkuk.ac.kr> + * Ported from FreeBSD to RTEMS March 16, http://sslab.konkuk.ac.kr + * + * The license and distribution terms for this file may be + * found in the file LICENSE in this distribution or at + * http://www.rtems.org/license/LICENSE. + */ + +/*- + * Copyright (c) 2011, Bryan Venteicher <mailto:bry...@freebsd.org> + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice unmodified, this list of conditions, and the following + *disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + */ + +#include +#include + +#include +#include + +#include +#include +#include +#include +#include + +#include + +#include +#include + +#include + +#include "virtio.h" +#include "virtio_pci.h" +#include "if_vtnet.h" + +static struct vtnet_softc vtnet_softc; +static rtems_interval vtnet_ti
RE: [PATCH] pc386: Add virtio network driver
Hi All, Thanks for your comments and suggestions. For a better decision, we like to give a bit of background of our patch. Initially, we got a comment from Joel that the pc386 BSP might be a suitable path for our patch as follows: https://lists.rtems.org/pipermail/devel/2016-March/014157.html Though we didnt discuss more about this issue at that time, he suggested the pc386 path maybe simply because our implementation only worked with pc386. In fact, however, most of our codes are architecture-independent, but the codes for memory barrier are troublesome. If there are architecture-independent wrapper functions for memory barrier in RTEMS, we can simply avoid the architecture dependency by exploiting those. However, we couldnt find such wrapper functions; thus, our patch includes few lines of assembly instructions of pc386. Now we are working on memory barrier for Sparc. Please let us know if we are missing something here. Based on Pavels suggestions, we think that the files of our patch can be placed as follows: libbsp/i386/pc386/virtio: virtio.h libbsp/shared: virtio.c, virtio_pci.c, virtio_pci.h, virtqueue.c, virtqueue.h, virtio_ring.h libchip/network: if_vtnet.c, if_vtnetvar.h, virtio_net.h However, in FreeBSD, all files to implement virtio are placed in the same directory, sys/dev/virtio. In addition, we are not familiar with libbsd yet. Thus, if our patch can be included in the mainline, it will be easier to continuously contribute to the virtio implementation from our side. Jin-Hyun -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber Sent: Wednesday, June 01, 2016 2:30 PM To: Chris Johns ; devel@rtems.org Subject: Re: [PATCH] pc386: Add virtio network driver On 01/06/16 06:42, Chris Johns wrote: >> The RTEMS driver infrastructure is not capable enough to deal with a >> plug-and-play architecture like x86. > > This does not make sense to me and I fail to see how it relates to the > previous statement. The original classic API for RTEMS is based on a > VME bus standard and while not a hot swap bus architecture it did > allow a plug in architecture based on a huge range of slave boards. > The fact an architecture or bus has plug-and-play support does not > mean RTEMS has to provide such support nor a BSP has reached a dead > end because it does not. The standard RTEMS driver infrastructure offers no support for auto-configuration, power-management, hot-plug and so on. The FreeBSD newbus infrastructure offers all of this. I don't think it make sense to add or event develop on our own such a functionality on a per-BSP basis. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ 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: [PATCH] pc386: Add virtio network driver
Thanks for the comments. We are trying to either use the compiler memory barrier as you people suggested or simply define the variables as volatile. We plan to repost the revised patch in a week. Since new patch would be no longer architecture-independent, we are thinking to locate the files at c/src/lib/ilbbsp/shared/. Hope this makes sense. Thanks, Jin-Hyun From: Joel Sherrill [mailto:j...@rtems.org] Sent: Tuesday, June 14, 2016 11:55 PM To: Gedare Bloom Cc: Jinhyun ; j...@konkuk.ac.kr; devel@rtems.org Subject: Re: [PATCH] pc386: Add virtio network driver Does the virtio.h file need to be in the BSP or is it independent and can move to shared? I am glad to see this code being BSP and architecture independent. :) On Tue, Jun 14, 2016 at 9:37 AM, Gedare Bloom <mailto:ged...@rtems.org> wrote: Or maybe just the RTEMS_COMPILER_MEMORY_BARRIER()? On Tue, Jun 14, 2016 at 10:37 AM, Gedare Bloom <mailto:ged...@rtems.org> wrote: > Does _CPU_atomic_Fence() work for you? It is defined in > cpukit/score/cpu/*/rtems/score/cpuatomic.h > > On Sat, Jun 11, 2016 at 3:12 AM, Jinhyun <mailto:jinh...@konkuk.ac.kr> wrote: >> Hi All, >> >> Thanks for your comments and suggestions. For a better decision, we like to >> give a bit of background of our patch. >> >> Initially, we got a comment from Joel that the pc386 BSP might be a suitable >> path for our patch as follows: >> https://lists.rtems.org/pipermail/devel/2016-March/014157.html >> Though we didn’t discuss more about this issue at that time, he suggested >> the pc386 path maybe simply because our implementation only worked with >> pc386. In fact, however, most of our codes are architecture-independent, but >> the codes for memory barrier are troublesome. If there are >> architecture-independent wrapper functions for memory barrier in RTEMS, we >> can simply avoid the architecture dependency by exploiting those. However, >> we couldn’t find such wrapper functions; thus, our patch includes few lines >> of assembly instructions of pc386. Now we are working on memory barrier for >> Sparc. Please let us know if we are missing something here. >> >> Based on Pavel’s suggestions, we think that the files of our patch can be >> placed as follows: >> libbsp/i386/pc386/virtio: virtio.h >> libbsp/shared: virtio.c, virtio_pci.c, virtio_pci.h, virtqueue.c, >> virtqueue.h, virtio_ring.h >> libchip/network: if_vtnet.c, if_vtnetvar.h, virtio_net.h >> However, in FreeBSD, all files to implement virtio are placed in the same >> directory, sys/dev/virtio. >> >> In addition, we are not familiar with libbsd yet. Thus, if our patch can be >> included in the mainline, it will be easier to continuously contribute to >> the virtio implementation from our side. >> >> Jin-Hyun >> >> -Original Message- >> From: devel [mailto:mailto:devel-boun...@rtems.org] On Behalf Of Sebastian >> Huber >> Sent: Wednesday, June 01, 2016 2:30 PM >> To: Chris Johns <mailto:chr...@rtems.org>; mailto:devel@rtems.org >> Subject: Re: [PATCH] pc386: Add virtio network driver >> >> >> >> >> On 01/06/16 06:42, Chris Johns wrote: >>>> The RTEMS driver infrastructure is not capable enough to deal with a >>>> plug-and-play architecture like x86. >>> >>> This does not make sense to me and I fail to see how it relates to the >>> previous statement. The original classic API for RTEMS is based on a >>> VME bus standard and while not a hot swap bus architecture it did >>> allow a plug in architecture based on a huge range of slave boards. >>> The fact an architecture or bus has plug-and-play support does not >>> mean RTEMS has to provide such support nor a BSP has reached a dead >>> end because it does not. >> >> The standard RTEMS driver infrastructure offers no support for >> auto-configuration, power-management, hot-plug and so on. The FreeBSD newbus >> infrastructure offers all of this. I don't think it make sense to add or >> event develop on our own such a functionality on a per-BSP basis. >> >> -- >> Sebastian Huber, embedded brains GmbH >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> Phone : tel:%2B49%2089%20189%2047%2041-16 >> Fax : tel:%2B49%2089%20189%2047%2041-09 >> E-Mail : mailto:sebastian.hu...@embedded-brains.de >> PGP : Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> >> ___ >> devel mailing list >> mailto:devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> >> >> >> >> ___ >> devel mailing list >> mailto:devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list mailto: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
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
RE: Update virtio network driver
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
Cc: devel@rtems.org; j...@konkuk.ac.kr
Subject: Re: Update virtio network driver
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
