Message-ID: <555E0683.6020600@redhat.com>
Date: Thu, 21 May 2015 18:23:31 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>
CC: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, bsd@redhat.com
Subject: Re: [PATCH 08/12] KVM: x86: save/load state on SMM switch
References: <1431084034-8425-1-git-send-email-pbonzini@redhat.com> <1431084034-8425-9-git-send-email-pbonzini@redhat.com> <20150521162036.GA31183@potion.brq.redhat.com>
In-Reply-To: <20150521162036.GA31183@potion.brq.redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1367
Lines: 38


On 21/05/2015 18:20, Radim Krčmář wrote:
> 2. NMI -> SMI -> IRET -> RSM -> NMI
> NMI is injected;  I think it shouldn't be ... have you based this
> behavior on the 3rd paragraph of SDM 34.8 NMI HANDLING WHILE IN SMM
> ("A special case [...]")?

Yes.

> Why I think we should restore NMI mask on RSM:
> - It's consistent with SMI -> IRET -> NMI -> RSM -> NMI (where we,
>   I think correctly, unmask NMIs)

Yes, we do.

> and the idea that SMM tries to be to
>   transparent (but maybe they didn't care about retarded SMI handlers).

That's my reading of that paragraph of the manual. :)

> - APM 2:15.30.3 SMM_CTL MSR (C001_0116h)
>   • ENTER—Bit 1. Enter SMM: map the SMRAM memory areas, record whether
>     NMI was currently blocked and block further NMI and SMI interrupts.
>   • EXIT—Bit 3. Exit SMM: unmap the SMRAM memory areas, restore the
>     previous masking status of NMI and unconditionally reenable SMI.
>   
>   The MSR should mimic real SMM signals and does restore the NMI mask.

No idea...  My implementation does restore the previous masking status,
but only if it was "unmasked".

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/