From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/8] Nested SVM unit tests Date: Wed, 28 Jul 2010 14:53:59 +0300 Message-ID: <4C501A57.4010808@redhat.com> References: <1280312307-16686-1-git-send-email-avi@redhat.com> <20100728114029.GF26098@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" To: "Roedel, Joerg" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8483 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751134Ab0G1LyF (ORCPT ); Wed, 28 Jul 2010 07:54:05 -0400 In-Reply-To: <20100728114029.GF26098@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/28/2010 02:40 PM, Roedel, Joerg wrote: > On Wed, Jul 28, 2010 at 06:18:19AM -0400, Avi Kivity wrote: >> The following patchset adds a framework for nested SVM unit testing. As >> you may guess, future fixes and enhancements to nested SVM will require >> matching tests. > Cool stuff. I guess the third test failed (vmrun intercept check), > should be easy to fix. This is generally a very useful thing. > Yes. >> Currently, our nested SVM implementation has a 66.67% success rate using >> these tests. > Okay, thats the downside :-) Anyway, are KVM changes not realated to > nested-svm required to pass these tests too? Yes. These tests are run as part of autotest (well, I forgot to update kvm/test/x86/unittests.cfg). If something wants to be in 'master', it needs to pass these tests. So it will be a good idea to add tests for things that are liable to break as part of normal code churn, e.g. event injection. > How about fixes for race conditions? We had bugs in the past with lost > interrupts in the L2 guest which only showed up under very special > conditions that may be hard to reproduce directly. They may depend on an > L1 interrupt becoming pending for example. > (And I think we still have one bug in this area left which is not yet > root-caused) The test framework supports smp, so you can have the second vcpu do nasty stuff. The difficult part is when the failure depends on host state that is not visible to the guest. Perhaps we can add test-only hypercalls that allow the guest to manipulate this state (drop shadows, etc.) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.