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

From: Stefan Hajnoczi <stefanha@gmail.com>
To: Juan Quintela <quintela@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developer <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] KVM call for 2017-03-14
Date: Tue, 14 Mar 2017 16:03:38 +0800	[thread overview]
Message-ID: <20170314080338.GA13140@stefanha-x1.localdomain> (raw)
In-Reply-To: <871su1w9jc.fsf@secure.mitica>

[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]

On Mon, Mar 13, 2017 at 03:12:07PM +0100, Juan Quintela wrote:
> Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 12 March 2017 at 21:45, Juan Quintela <quintela@redhat.com> 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.
> 
> On a previous life, I have to work on making qemu pass Common Criteria.
> Not to be able to remove large bits of it that we were not interested
> was a mess (basically we care about kvm + a bunch of devices, but it was
> impossible to remove things like TCG).

There was a project to move the build system to Kconfig.  Today some
block drivers can be loaded at run-time instead of built into the QEMU
binary.

Actually we don't need Kconfig if we continue developing module support.
For example, if accelerators become modules then you simply don't ship
or load the TCG and qtest modules.

ISTR the next are to modularize was ui/ so that GTK, SDL, SPICE, etc can
be loaded on-demand and do not need to be included in the core QEMU
package.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]