From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [ANNOUNCE] Native Linux KVM tool Date: Fri, 08 Apr 2011 11:11:34 +0200 Message-ID: <4D9ED146.7040004@siemens.com> References: <1301592656.586.15.camel@jaguar> <4D982E89.8070502@redhat.com> <4D9847BC.9060906@redhat.com> <4D98716D.9040307@codemonkey.ws> <4D9873CD.3080207@redhat.com> <20110406093333.GB6465@elte.hu> <4D9E6F6E.9050709@codemonkey.ws> <4D9EBBC3.2040803@siemens.com> <1302251236.27918.31.camel@jaguar> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Ingo Molnar , Avi Kivity , "linux-kernel@vger.kernel.org" , "aarcange@redhat.com" , "mtosatti@redhat.com" , "kvm@vger.kernel.org" , "joro@8bytes.org" , "asias.hejun@gmail.com" , "gorcunov@gmail.com" To: Pekka Enberg Return-path: In-Reply-To: <1302251236.27918.31.camel@jaguar> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 2011-04-08 10:27, Pekka Enberg wrote: > Hi Jan, > > On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote: >> I agree that it's easy to change 2kSomething LOC for this. But if you >> now wait too long designing in essential features like SMP, a scalable >> execution model, and - very important - portability (*), it can get >> fairly painful to fix such architectural deficits later on. How long did >> it take for Linux to overcome the BKL? QEMU is in the same unfortunate >> position. > > Yup, and we're taking your feedback seriously (and are thankful for > it!). We're hoping to look at SMP in the near future - help is > appreciated! Honestly, I do not yet see a major advantage for us to invest here instead of / in addition to continuing to improve QEMU. We've spend quite some effort on the latter with IMO noteworthy results. Porting over qemu-kvm to upstream was and still is among those efforts. We (*) are "almost done". :) Just one example: Despite QEMU's current deficits, I just have add a handful of (ad-hoc) patches to turn it into a (soft) real-time hypervisor, and that also for certain non-Linux guests. Your approach is yet man years of development and stabilization effort away from getting close to such a level. Don't want to discourage you or other contributors. I wish you that this approach can gather the critical mass and momentum to make it a real alternative, at least for a subset of use cases. We will surely keep an eye on it and re-assess its pros&cons as it progresses. Jan (*) the QEMU & KVM community -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux