OpenBSD Journal

g2k16 Hackathon Report: Mike Larkin on vmm + vmd progress

Contributed by pitrh on from the virtually puffed dept.

The first developer report from the just concluded g2k16 hackathon comes from Mike Larkin, who writes:

I worked on vmm/vmd. I had been sitting on a diff since Nantes that implements a real interrupt controller. This is so that we can have real hardclock interrupts and avoid the previous clock hack that made vmd(8) spin at 100% CPU usage.
Once I had that done, I cleaned up and refactored some vmd code, separating out each device into its own module/file. This made it easier for stefan@ to add asynchronous interrupt handling via libevent later in the week.

I next fixed the MSR (model specific register) bitmap. This is a giant mask that tells the processor which MSRs to allow the guest VM direct access to. Some are safe, some aren't, and some don't make sense at all in a VM. This bitmap is now locked down to just the minimial set of MSRs needed for well-behaved guest VMs (and those that aren't well behaved will think they are accessing off-limits MSRs but we just discard writes and return 0s on read).

I also removed some CPUID feature bits exposed to guest VMs, again removing things that aren't implemented or don't make sense in the guest VM (like the various thermal management/speedstep bits).

I wrapped up the week by dusting off my diff to provide a real BIOS inside the guest VM, that will make it easier to boot other types of guests by not having to go through vmd's ELF bootloader. This last bit did not get completed, and that's what I'm working on now.

Thanks to the organizers avsm and Gemma, it was a fun week.

Thanks for the report and all the awsome work on the virtualization system, Mike!

(Comments are closed)

Comments

  1. By Anonymous Coward (162.247.72.7) on

    Thank you for all the work on VMM!

    Are there any plans for DMA-remapping to protect physical hardware's memory from being accessed by other physical hardware, or is that already built in?

    Hardware Assisted Remapping for Protection

    Comments

    1. By mlarkin (107.77.75.110) on

      This is not presently needed as vmm does not do device passthrough. If and when that is implemented, then VT-d or equivalent technology will be used.

      Comments

      1. By Anonymous Coward (35.0.127.52) on

        > This is not presently needed as vmm does not do device passthrough. If and when that is implemented, then VT-d or equivalent technology will be used.

        What about the case for non-vmm use? For example, I do not want the firmware on my network card being able to read memory directly from my other hardware, such as other network card(s), graphics card, etc?

        Comments

        1. By Chris Cappuccio (chriscappuccio) on http://www.nmedia.net/chris/

          > > This is not presently needed as vmm does not do device passthrough. If and when that is implemented, then VT-d or equivalent technology will be used.
          >
          > What about the case for non-vmm use? For example, I do not want the firmware on my network card being able to read memory directly from my other hardware, such as other network card(s), graphics card, etc?

          There was an attempt to port the sparc64 iommu driver, however this was abandoned. You can find it in the attic.

  2. By Bobby Johnson (216.160.131.170) on

    Sweet!

    How ready for use is vmm / vmd at the moment? Will it be enabled by default in 6.1?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]