On 2011-12-15 12:54, Avi Kivity wrote: > On 12/15/2011 12:33 PM, Jan Kiszka wrote: >>>> >>>> Any thoughts on the qemu-kvm merge plan? Sounds painful. >>> >>> Pain will be where the existing qemu-kvm extensions collide with these >>> refactored upstream devices (backend/frontend split specifically). >>> That's where we have to merge very carefully. Haven't tried this yet, >>> will give it a spin tomorrow or so. >> >> Done yesterday, still seems to work fine. The result can be found at >> >> git://git.kiszka.org/qemu-kvm.git kvm-irqchip-merge >> >> The integration of the upstream irqchip patches was, as expected, not >> that hard. But the merge of my earlier refactorings, the >> backend/frontend split-up caused some efforts. >> >> I'm not sure what to do with that branch. We could either try to merge >> it before pulling in an upstream version that includes the new irqchips. >> But that won't work without manual conflict resolution as well. Or the >> branch can serve as a reference for re-doing a merge later on. > > If we merge this before upstream, will the two sides end up equivalent? qemu-kvm will carry the new upstream bits but will keep them widely disabled until upstream is feature equivalent. Of course, merging the kvm-irqchip-merge only makes sense once the corresponding upstream queue was actually merged. > Sounds like it'll be pretty easy to resolve the conflicts if so. > Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
