From patchwork Wed Jul 6 12:18:59 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 9216279 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7785E60752 for ; Wed, 6 Jul 2016 12:19:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 68E20286F3 for ; Wed, 6 Jul 2016 12:19:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5D7C0286F5; Wed, 6 Jul 2016 12:19:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id C8317286F3 for ; Wed, 6 Jul 2016 12:19:38 +0000 (UTC) Received: from localhost ([::1]:33262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKlnm-0003X3-1x for patchwork-qemu-devel@patchwork.kernel.org; Wed, 06 Jul 2016 08:19:38 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKlnI-0003Ud-AK for qemu-devel@nongnu.org; Wed, 06 Jul 2016 08:19:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKlnE-0003eh-4L for qemu-devel@nongnu.org; Wed, 06 Jul 2016 08:19:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKlnD-0003eZ-SO for qemu-devel@nongnu.org; Wed, 06 Jul 2016 08:19:04 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 525FCD4D7E; Wed, 6 Jul 2016 12:19:03 +0000 (UTC) Received: from [10.36.112.48] (ovpn-112-48.ams2.redhat.com [10.36.112.48]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u66CJ0Od011281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jul 2016 08:19:01 -0400 To: Laszlo Ersek , Ashok Raj , seabios@seabios.org, qemu-devel@nongnu.org References: <20160622065324.23812-1-haozhong.zhang@intel.com> <20160706012619.ebiizdoqngkmur7a@hz-desktop> <234271213.4215596.1467785884526.JavaMail.zimbra@redhat.com> <20160706062832.py2denwwvhw24f52@hz-desktop> <395937dc-b61d-880c-8a62-545bfc88eb84@redhat.com> <761279c8-3386-398e-f76f-919e55a81b06@redhat.com> From: Paolo Bonzini Message-ID: <2af5d48b-4bcc-d25d-e41e-5c41cf74b631@redhat.com> Date: Wed, 6 Jul 2016 14:18:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <761279c8-3386-398e-f76f-919e55a81b06@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 06 Jul 2016 12:19:03 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH v3] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 06/07/2016 13:04, Laszlo Ersek wrote: > Actually, I think there is a bug in KVM at the moment. I ran the > following test: > > - modified OVMF to set the MSR to value 0x5 on just the BSP > - booted an i440fx and a Q35 (SMM-enabled) OVMF guest > - checked "rdmsr -a 0x3a" in both > - ran "pm-suspend" in both guests, woke them > - repeated the rdmsr command > > The result is that the BSP had the 0x5 MSR value both after cold boot > and after S3 resume. So, KVM does not seem to implement clearing of the MSR. I suspect that the KVM module is getting in the way. Try removing it or go lower-level. I did the following test: - Applied the following patch to x86/s3.c from kvm-unit-tests: - Compiled the latest SeaBIOS - Applied the QEMU patches for LMCE - ran the following: ../qemu/+build/x86_64-softmmu/qemu-system-x86_64 -display none \ --enable-kvm -m 512 -serial mon:stdio \ -cpu host,+vmx -kernel ./x86/s3.flat \ -global PIIX4_PM.disable_s3=0 -device isa-debug-exit,iobase=0xf4 and my output is: enabling apic FACS is at 0x1ffe0000 resume vector addr is 0x1ffe000c copy resume code from 0x400340 PM1a event registers at 600 Current value of MSR is 0x5 Value after S3 resume is 0 I also tried using BITS from https://biosbits.org/downloads/bits-2073.zip with OVMF: >>> import bits >>> cpu = bits.cpus()[0] >>> bits.rdmsr(cpu, 0x3a) 0L >>> bits.wrmsr(cpu, 0x3a, 5) True >>> bits.rdmsr(cpu, 0x3a) 5L After a full system reset (I don't know if BITS can do S3! :)) the rdmsr gave zero again. Tracing KVM confirmed that the OVMF I used doesn't touch the MSR. > I checked kvm/next (currently at > 196f20ca52e8c7281932663c348fa54b82d03914), and vmx_vcpu_reset() does not > seem to zero vmx->msr_ia32_feature_control. This is true, but QEMU does zero it. > Now, what I absolutely can't tell you is whether this zeroing should > happen regardless of "init_event", or just for a specific value of > "init_event". Whenever I look at "init_event", I have to track it down > to the commit that added it, then locate all the commits that fixed it, > then guess whether the SDM language "logical processor reset" implies a > specific "init_event" value or not. So, I have no idea about "init_event". It should be preserved by INIT, but not by reset or S3. > So I need to know whether those INIT-SIPI-SIPI sequences are supposed to > clear the MSR -- in other words, whether I have to write patches that > explicitly sustain the MSR across these IPIs. No, INIT hardly changes any MSR. Paolo diff --git a/x86/s3.c b/x86/s3.c index cef956e..0f2b48f 100644 --- a/x86/s3.c +++ b/x86/s3.c @@ -1,6 +1,7 @@ #include "libcflat.h" #include "x86/acpi.h" #include "asm/io.h" +#include "x86/processor.h" u32* find_resume_vector_addr(void) { @@ -62,6 +63,7 @@ int main(int argc, char **argv) rtc_out(RTC_HOURS_ALARM, RTC_ALARM_DONT_CARE); rtc_out(RTC_REG_B, rtc_in(RTC_REG_B) | REG_B_AIE); + printf("Current value of MSR is 0x%x\nValue after S3 resume is ", (int)rdmsr(0x3a)); *(volatile int*)0 = 0; asm volatile("outw %0, %1" :: "a"((short)0x2400), "d"((short)fadt->pm1a_cnt_blk):"memory"); while(1) @@ -75,6 +77,13 @@ asm ( ".global resume_end\n" ".code16\n" "resume_start:\n" + "mov $0x3a, %ecx\n" + "rdmsr\n" + "mov $0x3f8, %dx\n" + "add $0x30, %al\n" + "out %al, %dx\n" + "mov $0xa, %al\n" + "out %al, %dx\n" "mov 0x0, %eax\n" "mov $0xf4, %dx\n" "out %eax, %dx\n"