From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Maydell Subject: Re: [Qemu-devel] KVM call for 2017-03-14 Date: Mon, 13 Mar 2017 11:02:01 +0100 Message-ID: References: <87tw6y8bs8.fsf@secure.mitica> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: KVM devel mailing list , QEMU Developer To: Juan Quintela Return-path: Received: from mail-wm0-f43.google.com ([74.125.82.43]:35830 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbdCMKCY (ORCPT ); Mon, 13 Mar 2017 06:02:24 -0400 Received: by mail-wm0-f43.google.com with SMTP id v186so36144920wmd.0 for ; Mon, 13 Mar 2017 03:02:22 -0700 (PDT) In-Reply-To: <87tw6y8bs8.fsf@secure.mitica> Sender: kvm-owner@vger.kernel.org List-ID: On 12 March 2017 at 21:45, Juan Quintela 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 ?] If the "VM support" usecase moves to another project then QEMU will become a very quiet backwater... - on the "emulation" side, nobody is clearly articulating a purpose for QEMU, a reason why you should use it rather than other modelling technologies (or rather than using real hardware). As a result the efforts applied to QEMU are somewhat unfocused. Are we trying to be: . a dev platform before easy h/w availability? [not easy for QEMU for several reasons] . a dev tool that provides better introspection into guest behaviour than running on h/w? [if so we should put more work into improving our introspection and guest tracing capabilities!] . primarily a tool for doing automated CI testing and one-off developer smoke-testing that's easier to set up and scale than trying to test on real h/w? . something else? [your idea goes here!] - in all areas our legacy code and back-compatibility requirements are threatening to choke forward progress if we don't make serious efforts to get on top of them - there's no easy way for people to use parts of QEMU like the CPU emulation, or to add their own devices without having to write lots of C code (we're firmly in a "one monolithic blob of code" setup right now and disentangling and setting clear API dividing lines will be a lot of work) [Making QEMU more modular would help with defeating the legacy and back-compat dragons, though] thanks -- PMM