[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ytl+BGei3zUlHY6l@google.com>
Date: Thu, 21 Jul 2022 16:25:40 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Maxim Levitsky <mlevitsk@...hat.com>
Cc: Santosh Shukla <santosh.shukla@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Tom Lendacky <thomas.lendacky@....com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2 4/7] KVM: SVM: Report NMI not allowed when Guest busy
handling VNMI
On Thu, Jul 21, 2022, Maxim Levitsky wrote:
> On Thu, 2022-07-21 at 16:08 +0000, Sean Christopherson wrote:
> > So we have a poor man's NMI-window exiting.
>
> Yep, we also intercept IRET for the same purpose, and RSM interception
> is also a place the NMI are evaluated.
>
> We only single step over the IRET, because NMIs are unmasked _after_ the IRET
> retires.
Heh, check out this blurb from Intel's SDM:
An execution of the IRET instruction unblocks NMIs even if the instruction
causes a fault. For example, if the IRET instruction executes with EFLAGS.VM = 1
and IOPL of less than 3, a general-protection exception is generated (see
Section 20.2.7, “Sensitive Instructions”). In such a case, NMIs are unmasked
before the exception handler is invoked.
Not that I want to try and handle that in KVM if AMD follows suit, I simply find
it amusing how messy this all is. A true NMI-window exit would have been nice...
Powered by blists - more mailing lists