Re: [Qemu-devel] KVM call for 2017-03-14

[Stefan Hajnoczi]

On Mon, Mar 13, 2017 at 11:02:01AM +0100, Peter Maydell wrote:
> On 12 March 2017 at 21:45, Juan Quintela <address@hidden> wrote:
> >
> >
> > Hi
> >
> > Please, send any topic that you are interested in covering.
> >
> > So far the agenda is:
> >
> > - Direction of QEMU and toolstack in light of Google Cloud blog:
> >   
> > https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html
> 
> 
> Ah, I'd forgotten that this was on the call agenda. I actually
> had an interesting conversation with Alex Graf last week about
> some similar topics, which I guess you could generally summarize
> as "what are the issues we need to address as a project in order
> to not become irrelevant in five years time". Since I wrote them
> up for an internal "what I did on my holi^Wconference trip" report
> I might as well repost them here:
> 
>   - on the "VM support" side, QEMU is more used because it's the only
>     production-quality option in this space, rather than because its
>     users love it. (cf the Google choice to replace it.) It's also got
>     a pretty poor security record. It wouldn't be too surprising if
>     some time in the next five years somebody writes a replacement in
>     a safer language (perhaps also targeting only the VM support role)
>     and it got enough mindshare and takeup to eclipse QEMU.
>     [Is it too early/daft to think about prototyping being able to
>      write QEMU device emulation in Rust ?]

We can move to a safer language starting with the device emulation
layer.  Keep the rest in C for now.  Use a language that has good C
interoperability or a convenient foreign function interface.

Start writing new device models in the new language.  Convert existing
devices if they are good candidates, like the e1000 NIC emulation.

The minimum requirements for the new language:
1. Does it support the host operating systems that QEMU runs on?
2. Does it support the host architectures that QEMU runs on?
3. Is it safer than C even when writing code to operate on guest RAM
   (i.e. it's no good if you must use unsafe primitives to do the
   systems programming tasks that QEMU requires)?
4. Is C interoperability convenient and high performance?

Stefan

signature.asc
Description: PGP signature