From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Make kvm header compile under g++. Date: Tue, 07 Apr 2009 20:11:44 +0300 Message-ID: <49DB8950.7090605@redhat.com> References: <217accd40903272153m650b0f1ata7bc899eb4b92be0@mail.gmail.com> <217accd40904061157r6f35dfe7r58b78678cb0e3aeb@mail.gmail.com> <49DB2805.7040401@redhat.com> <217accd40904070944p258080a2i8897212b471dd96b@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]:60488 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750902AbZDGRLQ (ORCPT ); Tue, 7 Apr 2009 13:11:16 -0400 In-Reply-To: <217accd40904070944p258080a2i8897212b471dd96b@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: nathan binkert wrote: >> btw, can you share what you're doing with kvm and g++? >> > > I am a researcher at HP Labs studying system architecture. For many > years, I have been involved in a simulator project called M5 > (m5sim.org). It shares a lot of things in common with qemu/kvm, > except instead of performance as our number one goal, measurement is > our number one goal. We model many aspects of computer systems in > detail trying to understand how to build future systems. We support a > number of architectures and are right now trying to finish x86 > support. We want M5 to be able to do everything x86 by itself, but I > was looking into the feasibility of using KVM as a fast "CPU" model to > help us get workloads running at an interesting point quickly at which > point we can switch over to a more detailed CPU model. Since M5 does > all of the modeling of memory, devices, and interrupts itself, this > really would use just the KVM bits and not use QEMU. We can also use > KVM in a single stepping mode to validate the correctness of the > simulator itself. > 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. > My initial playing around with the code looks pretty promising. The > only big question mark I have is how to deal with time. I really need > the simulator to control what the VCPU understands as the passage of > time (think about exactly when interrupts arrive, or exactly how VCPUs > advance with respect to each other when they're communicating through > shared memory). This has to be done to properly warm up the system. > I'm not concerned about whether I can do it at all. I just want to > make sure that I maintain the speed of KVM while I do it. > If you're interested in determinism, can't you just warm up the system once and then save the state? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.