Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 20 Jul 2018 15:26:56 +0200
From:   Radim Krcmar <rkrcmar@redhat.com>
To:     Paolo Bonzini <pbonzini@redhat.com>
Cc:     Wanpeng Li <kernellwp@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>, kvm <kvm@vger.kernel.org>,
        Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH v3 5/6] KVM: X86: Add NMI support to PV IPIs
Message-ID: <20180720132656.GB8330@flask>
References: <1530598891-21370-1-git-send-email-wanpengli@tencent.com>
 <1530598891-21370-6-git-send-email-wanpengli@tencent.com>
 <20180719163138.GC11749@flask>
 <CANRm+CwzG8jcsVhhGa2w55KcCTpwm-yokFR2Oi6LYaoS0ameqQ@mail.gmail.com>
 <825c953c-ec48-84cf-f1ca-bdee5d327427@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <825c953c-ec48-84cf-f1ca-bdee5d327427@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

2018-07-20 10:04+0200, Paolo Bonzini:
> On 20/07/2018 05:53, Wanpeng Li wrote:
> >>> -     ret = kvm_hypercall3(KVM_HC_SEND_IPI, ipi_bitmap_low, ipi_bitmap_high, vector);
> >>> +     switch (vector) {
> >>> +     default:
> >>> +             icr = APIC_DM_FIXED | vector;
> >>> +             break;
> >>> +     case NMI_VECTOR:
> >>> +             icr = APIC_DM_NMI;
> >> I think it would be better to say that KVM interprets NMI_VECTOR and
> >> sends the interrupt as APIC_DM_NMI.
> 
> It's not KVM, this is arch/x86/kernel/kvm.c so the guest side.

Yes, I was preparing to drop the delivery mode bits as they are not
needed for NMI_VECTOR: real APIC can't send nor receive vectors 0-15, so
we could just say that NMI_VECTOR is sendable through this interface and
is delivered as APIC_DM_NMI.

I didn't realize that this allows the other delivery modes.  They are
not useful [1], but we don't really have a better use for the three
bits.  The only other option so far is extending the cluster index to
increase addressability ... I'm starting to reconsider as addressing
another few millions VCPUs would probably be even more useless.

Wanpeng, sorry for the confusion, feel free to use any version.
Document the hypercall layout, though,

thanks.

---
1: I think that OSes will use unicast INIT+SIPI as it's easier to call
   it after preparing structures for the new CPU;  SMI is pointless;
   LowestPriority shouldn't be supported; and Reserved (APIC_DM_REMRD)
   is reused for KVM unhalt, where unicast is most likely.