From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Make kvm header compile under g++. Date: Thu, 09 Apr 2009 19:10:25 +0300 Message-ID: <49DE1DF1.9060701@redhat.com> References: <217accd40903272153m650b0f1ata7bc899eb4b92be0@mail.gmail.com> <217accd40904061157r6f35dfe7r58b78678cb0e3aeb@mail.gmail.com> <49DB2805.7040401@redhat.com> <217accd40904070944p258080a2i8897212b471dd96b@mail.gmail.com> <49DB8950.7090605@redhat.com> <217accd40904071025hd712bdbo85622f6a847c8a4d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: nathan binkert Return-path: Received: from mx2.redhat.com ([66.187.237.31]:37858 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756613AbZDIQKb (ORCPT ); Thu, 9 Apr 2009 12:10:31 -0400 In-Reply-To: <217accd40904071025hd712bdbo85622f6a847c8a4d@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: nathan binkert wrote: >> Excellent. One of the things I'm trying hard to do is keep kvm from being a >> 'qemu accelerator' and generally useful for other projects. That is, I'm >> trying to keep the userspace interface neutral, and not to model exactly the >> hardware qemu provides but allow for other configurations. >> >> One example where we failed to do this is in mapping interrupts, where PIC >> IRQ line n was tied to IOAPIC INTI line n. This came back to bite us when >> qemu changed its model. >> >> So if you notice such issues in kvm please bring them up so we can fix them. >> > I certainly will, and I have noticed such things already. They're > mostly problems for me in libkvm at this point. I haven't noticed any > big problems with KVM itself yet. I'm going back and forth as to > whether or not I want to use libkvm at all, though if you're receptive > to changes to that interface, I'll definitely keep that in mind. On > the other hand, since I'm using C++, I may just write a C++ libkvm and > try to give it to you guys. I will try to work with the existing > libkvm for now though. > libkvm suffers from not abstracting things enough. Since it was rejected from upstream qemu, it is unlikely to survive for much longer (though I think it has merit, it shouldn't be the case that everyone has to keep reimplementing this stuff). > >> If you're interested in determinism, can't you just warm up the system once >> and then save the state? >> > We often do stuff like that. We drop checkpoints and run from the > checkpoints, but the problem with that is that we often change things > in such a way that you need to boot fresh again. If we change a > device model or the kernel there's no getting around it. There are > more subtle things though. For example, if you warm up a simulation > with a simulated Gigabit ethernet and then decide that you really > wanted 10 Gig, you can't just change it when you resume the checkpoint > because TCP takes a while to warm up. We could of course warm up > further from the checkpoint, but if you were to go in the reverse > direction 10G -> 1G, TCP starts dropping packets and it takes a long > time in a simulator to deal with that. If I can impose a good enough > notion of time, I can deal with those things. Determinism is another > issue altogether. Our simulator is deterministic, and we'd love to > keep that property, but that's even more difficult, unless we can > figure out a way to tell KVM to do something like "execute up to 100 > instructions right now". I'm pretty far from really worrying about > these problems. I do have lots of ideas and I know that there are a > bunch of papers out there that work on this sort of thing. > You could do that with performance counters, although it would require kernel changes. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.