From owner-soc-status@freebsd.org Mon Aug 17 09:10:07 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86F469BB37F for ; Mon, 17 Aug 2015 09:10:07 +0000 (UTC) (envelope-from stefanogarzarella@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA66F19E3; Mon, 17 Aug 2015 09:10:06 +0000 (UTC) (envelope-from stefanogarzarella@gmail.com) Received: by lbcbn3 with SMTP id bn3so77561710lbc.2; Mon, 17 Aug 2015 02:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=taXLAr2TyFj+AAS1/Ow/aaHzuNlIkBv94YUSrfmLfXA=; b=ettO/DOQ3/om0U7b1vGtU9uBetP7KigmIPEPKrIcJJBifGqQlrriBm2hl8Sq5yxY8C z9rB1R65Tn5RqyFtJUxAm4xjNR5CbQsaFTLq9zkcPCrv4dyGd5HBKiUhZtNpk/j/UaFc fDAZ4JTPsmiNGACFOJN2diPpAgey1zEcqAUuNbqCbi3mz/mM/OM2LvwQDe4L8fRYFjVx aWgPC0YzhZNLr3bZToCqVybStkP/fs8Y3b9+Drd0S2x2GLJF7yw+BsQPS0hP1VfBs1Iy 3Kvlq1nMFRN4jgpJiJpuupozADRuyKZ9H7d8HbfWa9F6R7Dx/hfYhQzWTcWMA4cOIFpH jXgQ== X-Received: by 10.152.23.4 with SMTP id i4mr329477laf.51.1439802605014; Mon, 17 Aug 2015 02:10:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.216.140 with HTTP; Mon, 17 Aug 2015 02:09:45 -0700 (PDT) From: Stefano Garzarella Date: Mon, 17 Aug 2015 11:09:45 +0200 Message-ID: Subject: ptnetmap on bhyve - final status report To: soc-status@freebsd.org Cc: Luigi Rizzo , Peter Grehan , Neel Natu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 09:10:07 -0000 Dear All, I finished the last step on my GSoC 2015 project ("A FreeBSD/bhyve version of the netmap virtual passthrough (ptnetmap) for VMs"). In the last week I tested my code and I added more comments in bhyve, vmm.ko, and netmap, to describe my work. I also added some lines in bhyve.8 man page to explain how use ptnetmap backend. My code is available here: https://svnweb.freebsd.org/socsvn/soc2015/stefano/ptnetmap/stable/10/ I used the 10-STABLE branch for my work. To get the patches of modified modules, you can follow the following steps on my stable/10 branch: - bhyve svn diff -r 287649 usr.sbin/bhyve - virtio-net svn diff -r 287649 sys/dev/virtio/network - vmm.ko svn diff -r 287649 lib/libvmmapi sys/modules/vmm sys/amd64 - netmap the changes will be shortly committed in HEAD and R10 by my mentor svn diff -r 287649 sys/conf/files sys/modules/netmap sys/dev/cxgbe \ sys/dev/netmap sys/net The ptnetmap support for linux-KVM and QEMU is available here: https://github.com/stefano-garzarella/ptnetmap I implemented ptnetmap on bhyve working on the following steps: - bhyve network backends I reused the code developed by Luigi Rizzo (my mentor) and Vincenz= o Maffione to support multiple backend in bhyve and to interface the= m with a fronteds. The backends availabale are: - tap - netmap (netmap, vale) - ptnetmap (ptnetmap, ptvale) - ptnetmap support on virtio-net device for FreeBSD I modified the virtio-net guest device driver and the virtio-net fronted of thh host hypervisor (bhyve) to support ptnetmap. guest: - new PTNETMAP config flag in virtio-net device driver to check if ptnetmap is supported. - ptnetmap device-specific code (netmap - if_vtnet_netmap.h) host (hypervisor): - ptnetmap support on virtio-net fronted (bhyve - pci_virtio_ptnetmap.h) - ptnetmap backend [name: ptnetmap, ptvale] (bhyve - net_backends.c) - map netmap host memory into the guest I added a new IOCTL to vmm.ko to map an userspace guest buffer in the guest VM. Then I implemented a new PCI device (ptnetmap-memdev) to map the netmap host memory in the guest through PCI MEMORY-BAR. kernel host (vmm.ko): - new VM_MAP_USER_BUF ioctl to map buffer in the guest userspace host (bhyve): - vm_map_user_buf() in libvmmapi - ptnetmap=E2=80=90memdev device emulation (bhyve - pci_ptnetmap_memdev.c) kernel guest (netmap): - device driver for ptnetmap-memdev inluded in netmap module - ptnetmap support for FreeBSD host: I implemented kernel thread in netmap module to support ptnetmap o= n FreeBSD host. kernel host (netmap): - nm_os_kthread_*() functions to handle netmap kthreads. (netmap - netmap_freebsd.c ptnetmap.c) - netmap guest/host notification mechanisms. I needed two mechanisms: 1) notification from ptnetmap kthread to guest VM (interrupt/irq) vmm.ko already has IOCTL to send interrupt to the guest and I used it in the ptnetmap kernel threads. 2) notification from guest VM to ptnetmap kthread (write into the specific register) I added new IOCTL on vmm.ko (VM_IO_REG_HANDLER) to catch write/read on specific I/O address and send notification. For now I've implemented only one type of handler (VM_IO_REGH_KWEVENTS) to use these events in the kernel through wakeup() and tsleep()/msleep(), but I wrote the code to be easily extended to support other type of handler (cond_signal, write/ioctl on fd, etc). kernel host (vmm.ko): - new VM_IO_REG_HANDLER ioctl to catch write/read on specific I/O address and to choose an handler. (eg. wakeup(event_id) - vm_io_reg_handler() in libvmmapi kernel host (netmap) - msleep() on event_id. userspace host (bhyve) - vm_io_reg_handler(VTCFG_R_QNOTIFY, event_id) send guest notifications to ptnetmap kthreads when the guest writes on this virtio register (bhyve - pci_virtio_ptnetmap.h) - tell to netmap kthreads the event_id where they can wait for events Example: Run a 2GB single=E2=80=90CPU virtual machine with three network ports whic= h use netmap and ptnetmap backends: bhyve =E2=80=90s 0,hostbridge =E2=80=90s 1,lpc \ =E2=80=90s 2:1,virtio=E2=80=90net,vale0:1 \ /* normal v= ale backend */ =E2=80=90s 2:2,ptnetmap=E2=80=90memdev \ /* ptnetmap-memdev= is needed for each * ptnetmap port * (If two or more ptnetmap ports * share the same netmap memory allocator, * only one ptnetmap=E2=80=90memdev is required) */ =E2=80=90s 2:3,virtio=E2=80=90net,ptvale1:1 \ /* vale port= in ptnetmap mode * If "pt" prefix is used, the port * is opened in passthrough mode (ptnetmap) */ =E2=80=90s 2:2,ptnetmap=E2=80=90memdev \ =E2=80=90s 2:3,virtio=E2=80=90net,ptvale2{1 \ /* netmap-pi= pe in ptnetmap mode */ =E2=80=90s 3,ptnetmap=E2=80=90memdev \ =E2=80=90s 4,virtio=E2=80=90net,ptnetmap:ix0 \ /* NIC in ptne= tmap mode */ =E2=80=90l com1,stdio =E2=80=90A =E2=80=90H =E2=80=90P =E2=80=90m = 2G netmapvm I have results (obtained with pkt-gen) very close to linux/KVM and netmap host (both linux and FreeBSD) experiments (physical devices [14.88 Mpps], software switches [25 Mpps], shared memory channels [50 Mpps]). I used one instance of pkt-gen in the guest and the other one in the host. Thanks for your help! It was a pleasure working with you. Cheers, Stefano --=20 *Stefano Garzarella* Software Engineer e-mail: stefano.garzarella@gmail.com github: http://github.com/stefano-garzarella linkedin: http://it.linkedin.com/pub/stefano-garzarella From owner-soc-status@freebsd.org Mon Aug 17 17:42:23 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A54339BBA5A for ; Mon, 17 Aug 2015 17:42:23 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 312A4182D for ; Mon, 17 Aug 2015 17:42:23 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by wibhh20 with SMTP id hh20so87459140wib.0 for ; Mon, 17 Aug 2015 10:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eftZMaH7L3lHWmdwcW0CD31b8/GOUx//bVdsaOY6Q1U=; b=cSVYLiFImjs89veLUp2GA8URZ3ynA8qdBiH4OkSG9cVFA6VRx7QVSy0lnOThfZnt2c 5tZlwjSyXqDP/pfO39eeUqgD7f/V4KMUWS8CxTBIgnycts9HQtC/UavkGyCTXtc7n9Nn HRi8Z52tysRXlsTSOTnRtsrTGw/aUJhc+9plxRkFcrHAmtAns4Mlqf/osIZcgDovEol8 A8FXLGwLortpiLNh1vJjefvd979wVyMCeOhT8Dx/5j1SzFMSLoPX7lARERmjU77DhgLX LrrK3terEEK9s4RKyeF+4xiHRBCtvVhJeFXZ4/oLcERNbu5/VJJhjD3A6QmSu+FsaDTK YkJQ== MIME-Version: 1.0 X-Received: by 10.180.73.244 with SMTP id o20mr35859683wiv.31.1439833341525; Mon, 17 Aug 2015 10:42:21 -0700 (PDT) Received: by 10.28.21.132 with HTTP; Mon, 17 Aug 2015 10:42:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Aug 2015 20:42:21 +0300 Message-ID: Subject: Re: [GSOC] bhyve port on ARM - weekly status report From: Mihai Carabas To: soc-status@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:42:23 -0000 Hello everyone, > In the past week I managed to boot the guest all the way down to Interrupt >> Controller initialization [1]. There were minor bugs in the emulation code >> I had to fix. After that I've start reading the GIC ARM manual and tried to >> look at other vGIC implementations (virtualization of the Generic Interrupt >> Controller). I didn't get to write any code yet, I'm still trying to get >> the whole picture. This would be the last step before being able to run a >> guest (without timer virtualization - we can use an auxiliary timer mapped >> to the guest). >> > In the last week I've started coding on ARM VGIC infrastructure: > - I've created a new header file gic.h to export current registers to be > used by the VGIC > - I've exported the arm_gic_softc which is used to probe the VGIC specific > registers (I know it's unclean, but until I find a cleaner method, I will > go this way -> it's not so clear yet how much of the gic.c internals I will > need in the vgic.c) > - I've created in sys/arm/vmm/vgic.c the vgic_hyp_init function which is > probing the VGIC specific addresses from the DTS file, I've mapped the > virtual cpu control interface into hyp-mode (to be able to save/restore > these at each context switch) and saved the virtual cpu interface base for > later use > - I've created a new userspace ioctl VMM_ATTACH_VGIC which is sending the > physical address for the distributor that needs to be emulated and for the > cpu interface that will be mapped on top of the virtual cpu interface > - I've created a new function vgic_attach in sys/arm/vmm/vgic.c which is > called by the previous ioctl which is saving the userspace data, it's > initializing some structures and maps the cpu control interface > - We need to do an in-kernel emulation for the VGIC distributor. Further > I've created a new function called vgic_emulate_distributor which is called > in the vmm.c code (I know it's unclean, but I wanted to ressemble with x86 > in-kernel emulation and here I didn't have any defines for the emulated > addresses, I needed the struct hyp). The vgic_emulate_distributor is > calling vmm_emulate_instruction which specific handlers for read/write > emulation. > > I will push the code tomorrow. Right now I'm adding some printfs to check > that the flow for vgic distributor is working ok. > Further I've registered the MMIO callbacks for read/write the distributor memory ranges and added some prints in there (all the values are ok - now I have to take some actions based on them). Also I've saved and restore the VGIC state in the context switch code between Host-OS and VM. Right now the VM passes the Interrupt Controller initialization, initialize the directly mapped SP804 timer and after that I get some "spurious interrupts" in the guest due to lack of distributor emulation implementation. In the next week I try to implement some of the distributor operations. Thank you, Mihai From owner-soc-status@freebsd.org Tue Aug 18 10:38:00 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 243079BC67E for ; Tue, 18 Aug 2015 10:38:00 +0000 (UTC) (envelope-from tuchalia@gmail.com) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A53288C; Tue, 18 Aug 2015 10:37:59 +0000 (UTC) (envelope-from tuchalia@gmail.com) Received: by lbbtg9 with SMTP id tg9so100684623lbb.1; Tue, 18 Aug 2015 03:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=fnP8zjgoM2/ZDRwKAT0PGD58uBjK6B/sm8bH5D1Jbtg=; b=wiv0VZW1CksK+EE8+XKxUGx0ja4fUA4l73srRf84jOCGWjaVGLxtqRGcGe/6Q5hYU+ e4RIth9ibAdUQRCayLk5OmcePpOcwIJYl5Cb52BYXzjfrJNUhBxfsRVt/jlLXGiGzrT3 yGyrKATaVeJl53K1kcyIhQSW/caa9TnNHUbOxfJjembr7+rNFTUXNbF3WeKh4qgH6N4J jQfuiz/0q0EG3MKB13TcWEAMn9ccYVnVP3J3z+gRD217nsaKQKstYHKxzYSJO98IXE06 fueyp/N8vK4nY1ZGxHpPGe3rd1WARf3a1W2VMgXXXD0G5eQDkFeY8h5rS9RCvLhwS/YM SaQA== X-Received: by 10.152.37.67 with SMTP id w3mr5676857laj.123.1439894277387; Tue, 18 Aug 2015 03:37:57 -0700 (PDT) MIME-Version: 1.0 References: <358A0094-61DE-4685-933F-EDED85A6A07C@freebsd.org> In-Reply-To: From: Daniel Peyrolon Date: Tue, 18 Aug 2015 10:37:47 +0000 Message-ID: Subject: Re: Status reports for "JIT for firewalling" To: George Neville-Neil Cc: soc-status@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 10:38:00 -0000 Hi everyone, This past week I managed to complete one of the two final commands, and started working on it at the netperf cluster (in order to test it). I'm going to keep working on this after the SoC in order to get it done (after all, I'm going to use the firewall for my Master Thesis). If anyone is interested in how it's going, you can reach me out easily, or look for changes in my git repository (github.com/dplbsd/netmap-ipfwjit) or the wiki page. El lun., 10 ago. 2015 a las 10:16, Daniel Peyrolon () escribi=C3=B3: > Hi everyone, > > This week I managed to get code emission and compilation right for all > rules, except the three that modify the control flow. (skipto, call and > return). > These will be done this week. > > El jue., 6 ago. 2015 a las 10:38, George Neville-Neil () > escribi=C3=B3: > >> Great, I'll go look at the update etc. >> >> Best, >> George >> >> >> On 5 Aug 2015, at 22:49, Daniel Peyrolon wrote: >> >> > Yes, all of that is commited at my repo. >> > >> > El mar., 4 ago. 2015 a las 14:13, George Neville-Neil (> >) >> > escribi=C3=B3: >> > >> >> Sounds very promising. >> >> Have you committed an pushed the changes that made everything >> >> start to work? Even if that's just a set of notes, rather than code, >> >> that ought to be preserved. >> >> >> >> Best, >> >> George >> >> On 3 Aug 2015, at 9:15, Daniel Peyrolon wrote: >> >> >> >>> Hello, >> >>> >> >>> Finally we have the firewall working! >> >>> I get a kernel panic whenever I try to filter an unbounded number of >> >>> packets, but it doesn't when filtering a small amount of packets. >> >>> >> >>> The things to do now are: >> >>> - Test that the emission of all the new rules is working properly, a= nd >> >>> test that rule. >> >>> - Avoid kernel panic. This will take a longer time, but we need this >> in >> >>> order to get the firewall working in real-world systems. >> >>> - Write flow modifying rules: Given that I've been out of the game f= or >> >>> so long, I haven't been able to get those rules written yet, but >> luckily >> >>> they are only two rules, and its implementation shouldn't be hard. >> >>> >> >>> El lun., 27 jul. 2015 a las 20:36, Daniel Peyrolon (< >> tuchalia@gmail.com >> >>> ) >> >>> escribi=C3=B3: >> >>> >> >>>> Hi again, >> >>>> >> >>>> Unfortunately I haven't been able to make any further progress. >> >>>> I've been having a lot of problems to get the compiler working. I >> tested >> >>>> many different hypotheses about the bug with no success so far, and >> I've >> >>>> talked with David Chisnall to see if he could lend me a hand and he >> has >> >>>> given me some pointers. So, hopefully, I'll be past this stage this >> >> week. >> >>>> >> >>>> El lun., 20 jul. 2015 a las 15:43, George Neville-Neil (< >> >> gnn@freebsd.org>) >> >>>> escribi=C3=B3: >> >>>> >> >>>>> Seems like the next thing to do is build from source as David >> suggests. >> >>>>> >> >>>>> Best, >> >>>>> George >> >>>>> >> >>>>> >> >>>>> On 20 Jul 2015, at 4:47, Daniel Peyrolon wrote: >> >>>>> >> >>>>>> Hi everyone, >> >>>>>> >> >>>>>> This has not been a productive week. I've been so far unable to g= et >> >>>>>> the >> >>>>>> compiler working, I contacted David Chinsall as I said, and I hav= e >> >>>>>> been >> >>>>>> looking to make everything works. The initialization process of >> LLVM >> >>>>>> is not >> >>>>>> working as expected, which may be related to a bad install (we ha= ve >> >>>>>> already >> >>>>>> disarded that), a bad building process, or a bad LLVM >> initialization >> >>>>>> process. Given the fact that the LLVM API has changed a lot since >> the >> >>>>>> last >> >>>>>> time, that may be possible. >> >>>>>> >> >>>>>> El s=C3=A1b., 11 jul. 2015 a las 12:24, Daniel Peyrolon >> >>>>>> () >> >>>>>> escribi=C3=B3: >> >>>>>> >> >>>>>>> Hi everyone, >> >>>>>>> >> >>>>>>> This last pair of weeks I've written the code needed to compile >> >>>>>>> almost all >> >>>>>>> the rules, except those that modify control flow: call and skipt= o. >> >>>>>>> For >> >>>>>>> those ones I will have to write them by hand on LLVM IR. >> >>>>>>> >> >>>>>>> I also started working on the testing code. I'm using conductor = to >> >>>>>>> control the different hosts. I already have reserved a pair of >> hosts >> >>>>>>> from >> >>>>>>> the netperf cluster in order to get that running. >> >>>>>>> >> >>>>>>> So far I haven't been able to test anything because the compiler >> is >> >>>>>>> not >> >>>>>>> working yet, there has been a change in the API of LLVM since I >> last >> >>>>>>> worked >> >>>>>>> with it, I sent an email to my past mentor, David Chisnall askin= g >> for >> >>>>>>> advice. >> >>>>>>> -- >> >>>>>>> Daniel >> >>>>>>> >> >>>>>> -- >> >>>>>> Daniel >> >>>>> >> >>>> -- >> >>>> Daniel >> >>>> >> >>> -- >> >>> Daniel >> >> >> > -- >> > Daniel >> > -- > Daniel > --=20 Daniel From owner-soc-status@freebsd.org Tue Aug 18 11:05:37 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9589B9BCC5D for ; Tue, 18 Aug 2015 11:05:37 +0000 (UTC) (envelope-from ionutalex.teaca@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 574111C9A; Tue, 18 Aug 2015 11:05:37 +0000 (UTC) (envelope-from ionutalex.teaca@gmail.com) Received: by oio137 with SMTP id 137so98452508oio.0; Tue, 18 Aug 2015 04:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0qoWToHAThb1lwxkPf0bYn2K9tspV8PDDGMxU21vAX8=; b=OjtrFabZ96PFnRlAj7aClhjfY1PmOpemMkOzstrxWP9XXy+7GIgQj1ey8hAM2vlDeY wcfDEvse3u2VXnLwbp24kdtuZEsb8OYLVE6U2uPeIJuz4ic98+7AIwePMPm4Zp9DiaLU GMcqAUludu2IGn4DPjP9yJY/Ts7GM4B0mgVyYVuPZt0+QA2c1N7CiCgu5ImZJ82QNk8z BztBU2e/66umOa87gz/0UewbKDayMr1Z7ujg02V+5Z1KT+enVORK7FYTYz/OBn0fzkbm EEjqe5F35/m5tNvtm0Nln4VOSsw2HO5nlPCx6AGS5iS+wAs7xw3Sg8VW/5KfYtcoeGGC 6H/Q== MIME-Version: 1.0 X-Received: by 10.202.193.2 with SMTP id r2mr5183850oif.1.1439895936677; Tue, 18 Aug 2015 04:05:36 -0700 (PDT) Received: by 10.76.84.37 with HTTP; Tue, 18 Aug 2015 04:05:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Aug 2015 14:05:36 +0300 Message-ID: Subject: Re: GSOC 2015 - NE2000 emulation in bhyve Status From: Alex Teaca To: soc-status@freebsd.org Cc: Gavin Atkinson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 11:05:37 -0000 Hi, I've measured the performance of the NE2000 implementation. I will update the project wiki page with the results I've got. 2 commits related with the software reset state: - redesign the emulation of the CR register - implement the software reset workaround, and the software reset routine Practically, they've fixed a bug, because the emulator was able to receive traffic when the interface was down. From now on the packets are dropped. Started to research on the ISA attachment of the ne2k emulation. Thanks, Alex On Thu, Aug 6, 2015 at 12:29 AM, Alex Teaca wrote: > Hi, > > - handle the received multicast traffic > - accept the frames in the Promiscuous mode for the destination addresses > that do not match the station's address > > Thanks, > Alex > > > > On Wed, Jul 29, 2015 at 7:08 PM, Alex Teaca > wrote: > >> Hi, >> >> - I've added support for the read-only registers from the page0 >> - handle the monitor mode of the NIC >> - lock the reception flow with the .pe_barwrite and .pe_barwrite flows >> >> At the moment I am going to handle the multicast traffic and promiscuous >> mode. >> >> Thanks, >> Alex >> >> >> On Sat, Jul 11, 2015 at 12:27 PM, Alex Teaca >> wrote: >> >>> Hi, >>> >>> I've implemented the reception protocol of the NE2000 nic card. In order >>> to test it, I send in both directions (from guest to host and from host to >>> guest) big files (about 350M) >>> and it works without any problems. >>> >>> At the moment, I want to implement a mechanism to lock the access on the >>> shared resources between the tx and rx flows. >>> >>> Thanks, >>> Alex >>> >>> >>> >>> On Sun, Jun 28, 2015 at 7:16 PM, Alex Teaca >>> wrote: >>> >>>> Hi, >>>> >>>> From the last status report: >>>> >>>> implement 2 commits: >>>> - parse the input string parameter and get the tap name and mac address >>>> from it >>>> - implement some logging and asserts related with the receive buffer >>>> ring >>>> >>>> Also, I start to think about the receive protocol which is the next >>>> step of the implementation by reading the specification from the datasheet >>>> and understanding the implementation of the ED driver regarding the way >>>> it receives packets from the NE2000 memory. It is pretty clear >>>> what we need to implement and after a short design I will be able to >>>> implement. >>>> >>>> Thanks, >>>> Alex >>>> >>>> >>>> On Sun, Jun 14, 2015 at 11:37 PM, Alex Teaca >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> At the moment I am able to configure an IP address on the network >>>>> interface corresponding to the NE2000 NIC. When I ping >>>>> to the host IP, the tcpdump catches both ARP Request (sent by the >>>>> guest using the NE2000 card) and an ARP Reply >>>>> sent by the host OS. So, there is implemented the transmission >>>>> protocol. For reception, the packets are only read >>>>> from the tap device when it is notified by the mevent mechanism. >>>>> >>>>> For mode details, see the commits. >>>>> >>>>> Thanks, >>>>> Alex >>>>> >>>>> >>>>> On Tue, Jun 2, 2015 at 7:45 PM, Alex Teaca >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've started the implementation of the NE2000 module. At the moment >>>>>> the ED driver is able to probe the emulated device (RealTek 8029) and add >>>>>> it as a network interface. >>>>>> >>>>>> Some of the features which are implemented: >>>>>> - implement some logging support >>>>>> - clone the /usr/src/sys/dev/ed/if_edreg.h register interface from >>>>>> the ed driver into the bhyve tree sources >>>>>> - implement the NE2000 registers support and an API to access the NIC >>>>>> registers (get and set by offset) >>>>>> - design and implement the Remote DMA protocol so the ED driver can >>>>>> store and load from the NIC's RAM memory >>>>>> >>>>>> Thanks, >>>>>> Alex >>>>>> >>>>>> >>>>> >>>> >>> >> > From owner-soc-status@freebsd.org Sat Aug 22 14:04:00 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EEE09BDF9A for ; Sat, 22 Aug 2015 14:04:00 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D3342F9 for ; Sat, 22 Aug 2015 14:04:00 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by wicja10 with SMTP id ja10so36047366wic.1 for ; Sat, 22 Aug 2015 07:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eKa67CWBxAnMD5sR3C/z9IoSs07BlaXUScXS2dwDeLA=; b=UF0RLT0d3xJIbxb9kB1SsPccuCoABx8XIoq6fBAAa1RxFgWi3IvdnqeC7MVR3ILuaO kT2ACAx5SbCugdHtOgZTRdzJEGh8UE1OvDvaLO8PtG1ZWqjsHK+6TlROa7wVt+9pqDK5 4FTE5htYLXoas5A9STF0mHvXEFC6BK6OXajoj7pGgxSH/2WaGoqCFUcH7JJHGk8cse0j EFYyqwS8QDu2PwDPS/gQUziYmQ+MuS1AzxoPWZLT21Xa4X0fd9KtFp2Z/UMChNMzTlT0 xxL2sEornWKAup/bEo1wnIzCljqtSQfTy2/fwtM4S1sVuOYUTbmVwFoZ0xv1o/n3RPFW VfGw== MIME-Version: 1.0 X-Received: by 10.194.171.9 with SMTP id aq9mr25625292wjc.30.1440252237794; Sat, 22 Aug 2015 07:03:57 -0700 (PDT) Received: by 10.28.21.132 with HTTP; Sat, 22 Aug 2015 07:03:57 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Aug 2015 17:03:57 +0300 Message-ID: Subject: Re: [GSOC] bhyve port on ARM - weekly status report From: Mihai Carabas To: soc-status@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2015 14:04:00 -0000 Hello everyone, This is my final status report on this years's GSoC. I'm giving it today because the next week I will be away at a conference in Czech Replubic. In the last week I did work a little in the distributor emulation on the code handling the memory accesses, but the code isn't ready for commit. I've completed the wiki page [1] with the results where I've described every mechanism implemented in bhyve on ARM. I've also added some instruction on how to run FreeBSD on FastModels. I will continue my work on finishing the distributor emulation and using virtual timers for the Guests. I will come with some e-mails out of GSoC when the work will be ready to run easily on real-hardware. Thank you all, Mihai [1] https://wiki.freebsd.org/SummerOfCode2015/PortingBhyveToArm On Mon, Aug 17, 2015 at 8:42 PM, Mihai Carabas wrote: > Hello everyone, > > >> In the past week I managed to boot the guest all the way down to >>> Interrupt Controller initialization [1]. There were minor bugs in the >>> emulation code I had to fix. After that I've start reading the GIC ARM >>> manual and tried to look at other vGIC implementations (virtualization of >>> the Generic Interrupt Controller). I didn't get to write any code yet, I'm >>> still trying to get the whole picture. This would be the last step before >>> being able to run a guest (without timer virtualization - we can use an >>> auxiliary timer mapped to the guest). >>> >> In the last week I've started coding on ARM VGIC infrastructure: >> - I've created a new header file gic.h to export current registers to be >> used by the VGIC >> - I've exported the arm_gic_softc which is used to probe the VGIC >> specific registers (I know it's unclean, but until I find a cleaner method, >> I will go this way -> it's not so clear yet how much of the gic.c internals >> I will need in the vgic.c) >> - I've created in sys/arm/vmm/vgic.c the vgic_hyp_init function which is >> probing the VGIC specific addresses from the DTS file, I've mapped the >> virtual cpu control interface into hyp-mode (to be able to save/restore >> these at each context switch) and saved the virtual cpu interface base for >> later use >> - I've created a new userspace ioctl VMM_ATTACH_VGIC which is sending the >> physical address for the distributor that needs to be emulated and for the >> cpu interface that will be mapped on top of the virtual cpu interface >> - I've created a new function vgic_attach in sys/arm/vmm/vgic.c which is >> called by the previous ioctl which is saving the userspace data, it's >> initializing some structures and maps the cpu control interface >> - We need to do an in-kernel emulation for the VGIC distributor. Further >> I've created a new function called vgic_emulate_distributor which is called >> in the vmm.c code (I know it's unclean, but I wanted to ressemble with x86 >> in-kernel emulation and here I didn't have any defines for the emulated >> addresses, I needed the struct hyp). The vgic_emulate_distributor is >> calling vmm_emulate_instruction which specific handlers for read/write >> emulation. >> >> I will push the code tomorrow. Right now I'm adding some printfs to check >> that the flow for vgic distributor is working ok. >> > > Further I've registered the MMIO callbacks for read/write the distributor > memory ranges and added some prints in there (all the values are ok - now I > have to take some actions based on them). Also I've saved and restore the > VGIC state in the context switch code between Host-OS and VM. Right now the > VM passes the Interrupt Controller initialization, initialize the directly > mapped SP804 timer and after that I get some "spurious interrupts" in the > guest due to lack of distributor emulation implementation. In the next week > I try to implement some of the distributor operations. > > Thank you, > Mihai >