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

[Jan Kiszka <jan.kiszka@web.de>]

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

Jamie Lokier wrote:
> 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

VIA will soon (or already started to?) deliver working VT-x support with
their CPUs. As HVM also became a marketing tag, probably only very
resource-restricted systems will soon be sold without it, and on those
kqemu is no fun anyway (at best only for very very resource-restricted
guests).

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

That wouldn't change any of the technical problems it has. If we had no
broadly available HVM support today, /then/ you could bet that a kqemu
rewrite would be on the way, either driven by hobbyists or commercial use.

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

For that case (and Avi still haven written the API docs): Take (at
least) two people, one reading the source and writing that docs and the
others reading the docs and re-implementing a backend under whatever
license they want.

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

It's not that easy. The major design challenge is that kqemu is running
in cooperative mode with TCG, using the latter to handle cases the
in-kernel monitor cannot (or doesn't want to due to performance/latency
impact). Kvm does not need this as its guest-host switches are less
frequent and less heavy. We played with an approach to drive kqemu into
the same direction (patch and trap those un-virtualizable instructions)
and reduced the exists. The next step would have been to adopt kvm's I/O
handling philosophy (or even code), but problems of our approach on
heavily segmented guests stopped the effort.

There might have been another issue of the patch&trap approach:
self-checking guests (you can't easily hide the binary changes from the
guest). Then the only option would have been to translate the guest code
like TCG already does, but optimized for host = guest = x86. But that
effort would have been enormous and simply no longer worth it.


That said, I think the best one can do for kqemu remaining a qemu
citizen is to move it out of the way the latter wants to take, e.g.
eliminating the reason for

/* address in the RAM (different from a physical address) */
#ifdef CONFIG_KQEMU
/* FIXME: This is wrong.  */
typedef uint32_t ram_addr_t;
#else
typedef unsigned long ram_addr_t;
#endif

or reducing the impact of its hooks. One could, as another example, push
the hooks in cpu_in/out to helpers injected into the TCG output.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]