ptnetmap on bhyve status report

Stefano Garzarella stefanogarzarella at gmail.com
Tue Aug 4 16:40:35 UTC 2015


Dear All,
I recently ended the implementation of notification mechanism between vm and
ptnetmap kernel threads.

I needed two methods:
1) notification from ptnetmap kthread to guest VM (interrupt/irq)
       rx (host -> guest): new packets
       tx (guest - > host): new free slots

vmm.ko already has IOCTL to send interrupt to the guest and I used it in the
kernel thread.
The bhyve user-space, during netmap configuration, passes the ioctl
parameters
(fd, com, data) to ptnetmap kthreads.
The ptnetmap kthread (attached to bhyve process) uses kern_ioctl() with
these
parameters to notify the guest VM.


2) notification from guest VM to ptnetmap kthread (write into the specific
register)
       rx (host -> guest): new free slots
       tx (guest - > host): new packets

I added new IOCTL on vmm.ko (VM_IO_REG_HANDLER) to catch write/read
on specific I/O address and send notification.
These are the parameters:
 struct vm_io_reg_handler {
         uint16_t                port;                  /* I/O address */
         uint16_t                in;                     /* 0 out (write) -
1 in (read) */
         uint32_t                mask_data;      /* 0 means match anything
*/
         uint32_t                data;                 /* data to match */
         enum vm_io_regh_type    type;    /* type of handler */
         void                    *arg;                   /* argument used
from handler */
 };

For now I've implemented only 1 type of handler (VM_IO_REGH_KWEVENTS)
to use 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).

With this new IOCTL, when the guest writes on specific register, the vmm.ko
invokes
wakeup() on the parameter (arg / chan) specified from bhyve user-space
application.
The same parameter is passed to the ptnetmap kthreads that call
tsleep(chan, ...)
to wait the event.

In this way the netmap.ko and vmm.ko are independent and the event is
propagated
in the kernel, without passing through the user space.

Before the GSoC deadline, I'll do some performance experiments, code
cleanup and bug fixing.
The code is available on
https://svnweb.freebsd.org/socsvn/soc2015/stefano/ptnetmap/stable/10/


Any suggestions are appreciated.


Thanks,
Stefano Garzarella.


More information about the soc-status mailing list