Re: Cl-mirage Digest, Vol 7, Issue 12

["Yiming Zhang" <sdiris@xxxxxxxxx>]

Thanks to Gabor and Anil!

------------------                               
Yiming Zhang
2012-08-17

-------------------------------------------------------------
发件人：cl-mirage-request
发送日期：2012-08-17 04:00:12
收件人：cl-mirage
抄送：
主题：Cl-mirage Digest, Vol 7, Issue 12

Send Cl-mirage mailing list submissions to
        cl-mirage@xxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.cam.ac.uk/mailman/listinfo/cl-mirage
or, via email, send a message with subject or body 'help' to
        cl-mirage-request@xxxxxxxxxxxxxxx

You can reach the person managing the list at
        cl-mirage-owner@xxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cl-mirage digest..."


Today's Topics:

   1. Receiving Network Packets with Mirage/kFreeBSD (PALI Gabor Janos)
   2. Re: ELF Relocations and OCaml Code (Anil Madhavapeddy)
   3. Re: about "hello mirage world" (Anil Madhavapeddy)


----------------------------------------------------------------------

Message: 1
Date: Thu, 16 Aug 2012 15:13:27 +0200
From: PALI Gabor Janos <pgj@xxxxxxx>
Subject: Receiving Network Packets with Mirage/kFreeBSD
To: Anil Madhavapeddy <anil@xxxxxxxxxx>,        "Robert N. M. Watson"
        <robert.watson@xxxxxxxxxxxx>
Cc: cl-mirage@xxxxxxxxxxxxxxx
Message-ID: <20120816131326.GA15479@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

Hello there,

For your information, I have just added support for receiving network packets
to the kFreeBSD backend of mirage-platform:

https://github.com/pgj/mirage-kfreebsd/commit/c10b740218fd0af10e7b8e424d4cdde191edb251

Note that there is also a basic/netif test added to mirage-test/regress to
try this out and see it in action.

I would like to call for your reviews and comments.  To narrate on the design
choices I made, here is a brief summary on how the current implementation
looks like at the moment.

- After loading the built kernel module and starting up the evaluation of
  the Netif.create function, Mirage asks for a list of available Ethernet
  interfaces from the FreeBSD kernel and then assigns an lwt thread to each of
  them by "plugging".

- Plugged interfaces are stored in a linked list and have their ng_ether(4)
  hook (called from ether_input()) activated and pointed to
  netif_ether_input().  At the same time, there is a shared ring buffer
  created for each of them in Mirage then passed to the C function
  responsible for administering the list of plugged interfaces,
  caml_plug_vif().

- Shared ring buffers are created as Io_pages by allocating page-aligned,
  contiguous, multi-page memory areas via FreeBSD's contigmalloc(9).  These
  are directly accessible in Mirage as character arrays.

- Each shared ring buffer is currently of size 33 pages, and operates with
  2048-byte slots.  The buffers start with a header that maintains all the
  required meta information, like next position, available items, size of
  stored items.

- Each packet arriving on any of the plugged interfaces is placed to the next
  available slot of the corresponding shared ring buffer with m_copydata().

- In parallel with this in Mirage, the rx_poll function is run in loop that
  polls for available packets in the shared ring buffer.
  
- When rx_poll finds unprocessed packets then it runs the user-specified
  function on them, e.g. print the size of the packet in basic/netif.  It is
  implemented by passing a view on the Io_page, i.e. without copying.  After
  the user function has finished, the packet is removed from the ring.

- When no packets are available on the polled interface, rx_poll sleeps for a
  millisecond.

- Mirage is stopped when the kernel module is unloaded, which also involves
  unplugging the interfaces.

Let me add that shared rings do not do locking at the moment, but if you are
happy with the design I could proceed with implementing it.  (However, I am
not completely sure how to share locks between OCaml and C.)



------------------------------

Message: 2
Date: Thu, 16 Aug 2012 18:27:10 +0100
From: Anil Madhavapeddy <anil@xxxxxxxxxx>
Subject: Re: ELF Relocations and OCaml Code
To: PALI Gabor Janos <pgj@xxxxxxx>
Cc: cl-mirage@xxxxxxxxxxxxxxx
Message-ID: <20120816172710.GA1066@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

On Wed, Jul 25, 2012 at 12:19:08PM +0200, PALI Gabor Janos wrote:
> Hi,
> 
> Yesterday I had a strange issue with unsupported ELF relocations while
> building a kernel module out of OCaml programs for FreeBSD/amd64.  I have
> finally resolved the problem, but Anil suggested me to send in here for the
> record.
> 
> I am working on the FreeBSD port of the Mirage OS module.  Everything seemed
> to compile and link fine, until I wanted to load the module using the
> kldload(8) command:
> 
> # kldload mirage.ko
> 
> Then the console was pounded by lot of linker errors:
> 
> kldload: unexpected relocation type 9
> ...
> kldload: unexpected relocation type 4
> link_elf_obj: symbol camlPervasives__entry undefined
> linker_load_file: Unsupported file type
> 
> kldload: can't load mirage.ko: Exec format error
> 
> By browsing the kernel sources, it turned out that the 64-bit FreeBSD kernel
> does not support ELF relocation types 9 (R_X86_64_GOTPCREL), 10 (R_X86_32) and
> 4 (R_X86_64_PLT32) (among many others).
> 
> So, in order to get rid of these, I had to compile all my OCaml sources as
> position-dependent code, without support for dynamic linking.  This means that
> ocamlopt must be called with the following flags: -fno-PIC and -nodynlink.
> 
> In addition, a custom OCaml stdlib has to be built in the same fashion and
> used when compiling the sources.  (By the way, I use -output-obj to get a
> large C object file with all the referenced code, so it could be linked into
> the kernel module.)  This can be overridden by setting the CAMLLIB
> environmental variable.
> 
> However, note that, in the OCaml run-time sources (which gets finally linked
> to the generated object code) the file called amd64.S should be also modified
> to remove the last pieces of PIC addressing.  That is, the lines
> 
> #define GREL(r) r@GOTPCREL
> #define GCALL(r) r@PLT
> 
> should be rewritten as
> 
> #define GREL(r) r
> #define GCALL(r) r

This change in amd64.S came from:
http://caml.inria.fr/mantis/view.php?id=4795
...which added PIC support for amd64 around ocaml-3.12.

It looks like the way to fix it via a new SYS_kfreeBSD #define, as the
choice of runtime can't be dynamically toggled based on -fPIC at the
moment.  That would be a bigger patch, and probably best left to the OCaml
team to decide if it's necessary or not.

-anil



------------------------------

Message: 3
Date: Thu, 16 Aug 2012 18:32:27 +0100
From: Anil Madhavapeddy <anil@xxxxxxxxxx>
Subject: Re: about "hello mirage world"
To: PALI Gabor Janos <pgj@xxxxxxx>
Cc: cl-mirage <cl-mirage@xxxxxxxxxxxxxxx>, Yiming Zhang
        <sdiris@xxxxxxxxx>
Message-ID: <20120816173227.GB1066@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

On Tue, Jul 31, 2012 at 03:19:26PM +0200, PALI Gabor Janos wrote:
> Hi,
> 
> On Fri, Jul 27, 2012 at 02:41:01PM +0100, Yiming Zhang wrote:
> > First, it is required to "have mir-xen in your PATH", but where mir-xen is?
> > And second, the first step is to "cd mirage.git/regress", but where
> > mirage.git is?
> 
> I think it is because the documentation has not been updated.  There was a
> major reorganization for the Mirage sources: mirage.git has been split into
> multiple smaller repositories that now you can find under mirage.github.com
> (and install via using OPAM).
> 
> The old mirage.git repository lives at Anil's github's profile, that is where
> you could find the referenced files:
> 
> http://github.com/avsm/mirage.git
> 
> However, I do not know whether it would make any sense to use them any more.

Yes indeed. We're currently breaking up Mirage into a series of smaller
libraries that are easier to integrate as libraries (both for microkernel
use, and for general programming under UNIX).  

So the answer to your question really depends on what you're trying to do
with Mirage.  If you want to play with microkernels and Xen and
experiment, then monolithic repository that Gabor points out in:
http://github.com/avsm/mirage.git

...works perfectly fine, and the documentation at:
http://tutorial.openmirage.org/#1
should mostly be correct.

All new development is happening in the broken up repositories, and we're
aiming for a soft launch just before XenSummit in a couple of weeks.
http://xen.org/xensummit/xs12na_talks/xensummit.html

I'm afraid the broken-up new system will be somewhat subject to change
before then. Thomas is finishing up a major rev to OPAM which will improve
its stability with the 0.4 release, but there will likely be some
short-term fallout as a result.

-- 
Anil Madhavapeddy                                 http://anil.recoil.org



End of Cl-mirage Digest, Vol 7, Issue 12
****************************************