On Tue, May 09, 2017 at 11:24:49AM +0200, Paolo Bonzini wrote: > > Good, that was my understanding - and I wanted to single out this > conflict because > > 1) I wasn't even sure if Paul was aware of it, since the conflict > surprised me when doing my own trial merge. I'd like to be aware of > arch vs. KVM conflicts, just like Linus, so that I can relay the > information to him precisely; Stephen did mention it to me, but I didn't have it in mind when I sent the pull request. Sorry about that. > 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). The last two merge windows have seen a lot of changes in the PPC code, both generally and for KVM, because of the POWER9 support coming in. Compared to POWER8, POWER9 has a lot of very significant architecture changes specifically designed to benefit Linux and KVM, which is wonderful, but has also meant a lot of code changes. We're working on moving the assembly code to C where possible, and as Ben said, things are actually getting a lot simpler on POWER9 (though of course we'll have to keep supporting POWER8 for a while yet). > 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. There are certainly parts of the PPC KVM code that would naturally be considered as part of low-level machine enablement, and I think it does make sense for them to go via Michael. > 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. Point taken. Cheers, Paul.
