From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v2 7/8] KVM: nVMX: Require immediate-exit when event
 reinjected to L2 and L1 event pending
Date: Tue, 28 Nov 2017 12:14:23 +0100
Message-ID: <05242c26-8084-aa37-49b7-00f0a5c06ccc@redhat.com>
References: <1511278211-12257-1-git-send-email-liran.alon@oracle.com>
 <1511278211-12257-8-git-send-email-liran.alon@oracle.com>
 <CALMp9eTPi=ovCd8nyMtRR+MaHN_TvTVCTjKbcNoZ0Juipgd4CA@mail.gmail.com>
 <5A1C94B8.8040809@ORACLE.COM>
 <CALMp9eQdMaD_aW9ZCtAN6s+BY_coGZ19ahyvB5AVD-OfKb0KVA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        kvm list <kvm@vger.kernel.org>,
        Wanpeng Li <wanpeng.li@hotmail.com>,
        Idan Brown <idan.brown@oracle.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jim Mattson <jmattson@google.com>,
        Liran Alon <LIRAN.ALON@oracle.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:46170 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1755136AbdK1LO1 (ORCPT <rfc822;kvm@vger.kernel.org>);
        Tue, 28 Nov 2017 06:14:27 -0500
In-Reply-To: <CALMp9eQdMaD_aW9ZCtAN6s+BY_coGZ19ahyvB5AVD-OfKb0KVA@mail.gmail.com>
Content-Language: en-US
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 28/11/2017 05:55, Jim Mattson wrote:
> kvm_queue_interrupt() begins as follows:
>         vcpu->arch.interrupt.pending = true;
> 
> kvm_cpu_has_interrupt() begins as follows:
>         if (!lapic_in_kernel(v))
>                 return v->arch.interrupt.pending;
> 
> In the referenced [patch 2/8], you change interrupt.pending to
> interrupt.injected, but the same field is still referenced by these
> two functions.

We cannot remove the !lapic_in_kernel(v) case, but it's okay if we
restrict nested VMX/SVM in CPUID when it is disabled (that is, check for
!lapic_in_kernel in nested_svm_check_permissions and nested_vmx_allowed,
so that setting VMXE and SVME will fail).

Thanks,

Paolo