From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: NULL pointer dereference in kernel code, ignored parameters in libkvm Date: Mon, 25 May 2009 14:55:59 +0300 Message-ID: <4A1A874F.1040201@redhat.com> References: <4A1876BE.80103@eecs.umich.edu> <4A19369B.8020003@redhat.com> <4A19AD6C.8050805@eecs.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, nathan binkert , Steve Reinhardt To: Gabe Black Return-path: Received: from mx2.redhat.com ([66.187.237.31]:50398 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751143AbZEYL4P (ORCPT ); Mon, 25 May 2009 07:56:15 -0400 In-Reply-To: <4A19AD6C.8050805@eecs.umich.edu> Sender: kvm-owner@vger.kernel.org List-ID: Gabe Black wrote: >> It would also be interesting to hear how you use kvm. >> >> > > Ultimately, we'd like to use KVM for at least two things. The first is > as a way to fast forward simulations to the portion of interest before > switching into something slower that can collect interesting statistics > and accurately simulate performance. Our immediate goal on our way to > that is to get a CPU based around KVM to boot Linux while hooked into > our device models. We're very early in the process, but one challenge > I'm anticipating is being able to pull the local APIC out of the virtual > CPU and into M5 so that we can coordinate IPIs, etc., ourselves. > Since we support live migration, it should be doable. Tricky though. > The other thing we'd like to do is to use KVM as a golden model to > verify our correctness against. To do that, we'll probably need to make > significant progress on the above, and then also find a mechanism to > make each CPU advance in very incremental and deterministic ways. Our > thought on that so far as been to set the TF bit in the guest and use > the #DB to exit back to the host. We expect there will be some gotchas > with this like hold off on mov to %ss, but if there would be any show > stopper problems please let us know. > It should work as long as the guest doesn't debug itself, I think. May have problems with interrupts or NMIs. -- error compiling committee.c: too many arguments to function