From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 3/3] Add mce test Date: Mon, 06 Sep 2010 17:53:20 +0300 Message-ID: <4C850060.2000303@redhat.com> References: <20100902233652.853027771@redhat.com> <20100902233712.767024334@redhat.com> <4C835194.1020002@redhat.com> <20100905211722.GA3030@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11434 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750927Ab0IFOxY (ORCPT ); Mon, 6 Sep 2010 10:53:24 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o86ErNu3004118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Sep 2010 10:53:23 -0400 In-Reply-To: <20100905211722.GA3030@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 09/06/2010 12:17 AM, Marcelo Tosatti wrote: > On Sun, Sep 05, 2010 at 11:15:16AM +0300, Avi Kivity wrote: >> On 09/03/2010 02:36 AM, Marcelo Tosatti wrote: >>> + >>> +int main(void) >>> +{ >>> + unsigned long long status, addr; >>> + int bank; >>> + >>> + smp_init(); >>> + init_idt(); >>> + set_idt_entry(18, do_handle_mce); >>> + >>> + write_cr4(read_cr4() | X86_CR4_MCE); >>> + >>> + wrmsr(MSR_IA32_MCG_CTL, ~0ULL); >>> + wrmsr(MSR_IA32_MC0_CTL, ~0ULL); >>> + >>> + status = MCI_STATUS_VAL|MCI_STATUS_UC; >>> + addr = 0x7ffffff; >>> + bank = 0; >>> + ex_done = 0; >>> + /* mce cpu bank status mcgstatus addr misc */ >>> + monitor_printf("mce %d %d 0x%llx 1 0x%llx 1\n", 0, bank, status, addr); >> Wow, this is really evil. >> >> I guess it could be done more nicely via the api unit tests we >> talked about during kf2010? > I don't remember the details. Map gpa:hva 1:1; map gva:gpa 1:1; do direct calls between host userspace and guest kernel. Hope to post a patch soon. > What do you consider evil? Not really evil. It's a nice roundabout loop guest -> testdev -> chardev -> host -> chardev -> monitor -> kvm -> guest. Works well, but only for features that are directly controlled via the monitor. To test save/restore (for vcpu events or fpu) we need something more direct (guest -> host userspace -> guest). -- error compiling committee.c: too many arguments to function