From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrpWa-0003cr-R8 for qemu-devel@nongnu.org; Mon, 11 May 2015 11:21:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrpWV-00015I-AG for qemu-devel@nongnu.org; Mon, 11 May 2015 11:21:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrpWV-000159-22 for qemu-devel@nongnu.org; Mon, 11 May 2015 11:21:39 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4BFLcSe002540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 11 May 2015 11:21:38 -0400 Message-ID: <5550C8FE.8080804@redhat.com> Date: Mon, 11 May 2015 17:21:34 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1431352157-40283-1-git-send-email-pbonzini@redhat.com> <1431352157-40283-24-git-send-email-pbonzini@redhat.com> <5550C808.8000505@redhat.com> In-Reply-To: <5550C808.8000505@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 23/31] ich9: implement SMI_LOCK List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , kraxel@redhat.com Cc: qemu-devel@nongnu.org, mst@redhat.com On 11/05/2015 17:17, Laszlo Ersek wrote: > If I understand correctly, this makes SMI_LOCK lock down the GBL_SMI_EN > bit (and my OVMF patch that relies on that / tests it is satisfied too). > > But, it doesn't seem to lock down APMC_EN. According to the ICH9 spec, > it doesn't need to -- however when we discussed this earlier (see > Message-Id: <553F4D23.3060305@redhat.com>), the idea was to lock down > APMC_EN as well. (And I don't understand why the ICH9 spec / hw > implementation doesn't lock APMC_EN; without that, APM_CNT won't > necessarily trigger an SMI.) I don't think it should. See here where I wrote explicitly "Even if the OS tries to maliciously set APMC_EN to 0 (SMI_LOCK doesn't lock APMC_EN)...". Paolo