Re: [Qemu-devel] Re: [PATCH] remove pieces of source code

[Jamie Lokier <jamie@shareable.org>]

Jan Kiszka wrote:
> >  o There is no alternative for non-Linux users and folks with non-VT/SVM
> > hardware
> 
> The non-HVM argument will become widely irrelevant (for desktops) very
> soon.

Only if your looking at the virtualisation market.
As far as I know

    - There are no non-Intel, non-AMD CPUs which support HVM
    - Laptops are outselling desktops these days
    - Little low-power PCs are gaining in popularity at home

Personally I have HVM on one of my laptops but not the other.  I have
several "media player" nano-ITX PCs, and I don't think any of them
support HVM, even the Intel ones.  I have one dual-AMD desktop machine
which does not have HVM.  I have access to two big Intel Xeon servers.
Only one has HVM, and annoyingly the faster one does not have HVM,
even though it's 64-bit.

That's only 2 out 7 PC types I have ready access to which have HVM.

I do understand the wish to drop KQEMU, and I understand the wish of
the staff developers to not want to spend time supporting platforms
they aren't using themselves, and aren't their customers.  Especially
when it complicates the code base.

But it will make QEMU a less useful tool for some.

I suspect if QEMU development was still a "hobby" project, the
"coolness factor" of being able to do things like KQEMU would win over
"target market" rule which I guess is more motivating for paid developers.

Anyway, we had this discussion before and the obvious conclusion was
that the only viable way to keep KQEMU is if there are volunteers
stepping up to maintain it, both the userspace and kernel portions.

Or ideally, to replace it with something KVM-compatible, as that would
reduce the maintenance burden.

For replacing KQEMU on Linux, that's realistic I think.  Either it's
done, or there's no maintainer anyway.

But for non-Linux hosts I see a non-technical problem:

   - Without API documentation you have to read the KVM source code.

   - Those goes doubly so for the fiddly bits like kernel APIC
     emulation and virtio.

   - But it may not be legally safe to read the KVM source code and
     reimplement it in such detail for a GPL-incompatible target kernel.
     (It might be seen as a form of translation).

(We've already seen someone implementing a virtio driver on the list
who was worried about GPL implications).

So how can anyone implement a KVM-compatible replacement for KQEMU on
other host platforms?

-- Jamie