linux-kernel - Re: [PATCH v3 5/6] KVM: X86: Add NMI support to PV IPIs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180720132656.GB8330@flask>
Date:   Fri, 20 Jul 2018 15:26:56 +0200
From:   Radim Krcmar <rkrcmar@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Wanpeng Li <kernellwp@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, kvm <kvm@...r.kernel.org>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH v3 5/6] KVM: X86: Add NMI support to PV IPIs

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.