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

[Alex Bennée]

Peter Maydell <address@hidden> writes:

> 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 ?]

I think rust has the potential to be very interesting. I've been
watching to remacs project with interest:

  https://github.com/Wilfred/remacs

They are attempting to port Emacs to rust in a piecemeal way. Whether
this works remains to be seen but it is certainly an interesting
approach compared to other "re-write it all" approaches.

>     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!]

For example now we support atomics in the TCG it would be fairly easy* to
port something like the ThreadSanitizer (which has fairly hefty memory
requirements) as a tool for debugging system code.

>     . 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)

I spoke to Edgar about posting his rports patch set as a catalyst for
discussion. Certainly for modelling hobby projects or new hardware QEMU
could do with support for rapid prototyping. Others have mentioned maybe
including a scripting language integration for device modelling -
although I still hold the view that what ever language you choose will
be the "wrong one" according to the majority of developers.

>     [Making QEMU more modular would help with defeating the legacy
>     and back-compat dragons, though]
>
> thanks
> -- PMM


--
Alex Bennée