Re: [GIT PULL] Please pull my kvm-ppc-next branch again

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2017-05-09 at 11:24 +0200, Paolo Bonzini wrote:
> 2) I'm not sure about why PPC/KVM conflicts keep on happening.  KVM on
> PPC seems to be more tightly integrated with non-KVM code than other
> architectures.  _But it's also the other way round_ which seems less
> healthy to me.  I'm not sure if that is really necessary, but if not,
> please refactor things so that we don't step on each other's toes
> unnecessarily.  Perhaps real mode handlers should be in
> arch/powerpc/kernel/ and only arch/powerpc/kvm/, so that the latter only
> cares about virtualization?  Maybe the whole napping and CPU thread
> management should be done outside arch/powerpc/kvm/?  Not sure if that
> makes any sense, but to my eyes there are definitely too many KVM parts
> in hardware enablement patches (and BTW it's just crazy that PPC has
> about 4k lines of assembly).

Heh, we've been improving that lately :-)

> Maybe PPC *is* the special snowflake where interaction should be
> primarily with arch maintainers rather than myself.  Then let's just
> have topic branches for the occasional API patch (new KVM_CAP_*
> constants would be the gist of it) and otherwise let Michael merge
> KVM/PPC patches.

Sadly it *is* a bit of a special snowflake due to mostly two things,
which are the way the old hash MMU worked (the CPU wasn't designed for
a hypervisor operating with MMU on among other things, so we have this
whole business with doing things in "real mode"), and the way P8 forces
threads to be in the same partition.

We hope to be able to make a much simpler and much more classic
"backend" at some point with the new radix MMU for P9, though we'll
probably continue dragging some of that existing cruft as long as hash
still has to be supported among other things.

> But in any case, to my eyes there _is_ a pattern, and a problem.  It
> doesn't matter that the canary is a cherry-pick conflict that Linus
> could solve blinded and with one hand tied behind his back.

There is but it's more or less inherent to the CPU architecture. All I
can say is we are trying to move away from a lot of that crap with the
new MMU, but that will take time.

On thing that will help too is that we have been working hard to get
full hypervisor level backward compatibility for P9 onward. So
hopefully, there will be less overlap between pure enablement and KVM
in the future for that reason too.

Cheers,
Ben.