From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753225AbdJMRg2 (ORCPT <rfc822;w@1wt.eu>);
        Fri, 13 Oct 2017 13:36:28 -0400
Received: from mx1.redhat.com ([209.132.183.28]:57802 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752768AbdJMRg0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 13 Oct 2017 13:36:26 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C57884ACA7
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=rkrcmar@redhat.com
Date: Fri, 13 Oct 2017 19:36:21 +0200
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        kvm <kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
        Wanpeng Li <wanpeng.li@hotmail.com>
Subject: Re: [PATCH v2 4/4] KVM: LAPIC: Don't silently accept bad vectors
Message-ID: <20171013173620.GB16116@flask>
References: <1506647099-2688-1-git-send-email-wanpeng.li@hotmail.com>
 <1506647099-2688-5-git-send-email-wanpeng.li@hotmail.com>
 <20171003175341.GD21107@flask>
 <CANRm+CzRsdXMJxHN1zXgq2QX5z2dNJHV2HLXUaJz7KomdS6vGA@mail.gmail.com>
 <20171004120146.GC20277@flask>
 <CANRm+Cya1hz8fKH=BPuQ7tXpRc01jg+LW_7vCHz36kXqWNcuXg@mail.gmail.com>
 <20171004144444.GI21107@flask>
 <CANRm+CzDrw6-8+wDXon5bCbfTCg8MdCbnAsahNXEJuZdQn=C8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANRm+CzDrw6-8+wDXon5bCbfTCg8MdCbnAsahNXEJuZdQn=C8A@mail.gmail.com>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 13 Oct 2017 17:36:25 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

2017-10-13 09:17+0800, Wanpeng Li:
> 2017-10-04 22:44 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
> > 2017-10-04 22:16+0800, Wanpeng Li:
> >> 2017-10-04 20:01 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
> >> > 2017-10-04 15:56+0800, Wanpeng Li:
> >> >> 2017-10-04 1:53 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
> >> >> > 2017-09-28 18:04-0700, Wanpeng Li:
> >> >> >> @@ -946,6 +965,11 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,
> >> >> >>       int result = 0;
> >> >> >>       struct kvm_vcpu *vcpu = apic->vcpu;
> >> >> >>
> >> >> >> +     if (unlikely(vector < 16) && delivery_mode == APIC_DM_FIXED) {
> >> >> >> +             apic_error(apic, APIC_ESR_RECVILL);
> >> >> >
> >> >> > The error is also triggered if lowest priority is supported and tries to
> >> >> > deliver an invalid vector.
> >> >>
> >> >> Could you point out this in SDM? :)
> >> >
> >> > In section 10.5.3 Error Handling:
> >> >
> >> >   If the local APIC does not support the sending of lowest-priority IPIs
> >> >   and software writes the ICR to send a lowest-priority IPI with an
> >> >   illegal vector, the local APIC sets only the “redirectible IPI” error
> >> >   bit.
> >> >
> >> > Hence, if local APIC does support lowest-priority, then it throws the
> >> > same error as fixed.  (KVM does support lowest-priority.)
> >>
> >> Yeah, I read the section before but I misunderstand it. It seems that
> >> the section means it just occurs when the local APIC does not support
> >> the sending of lowest-priority IPIs?
> >
> > I think so.
> 
> I see Virtualbox just captures Fixed delivery mode for error handling.

Hm, it doesn't even inject an error on destination of the
lowest-priority interrupt and just drop it?

I can't interpret the SDM in any other way, though:

  When an interrupt vector in the range of 0 to 15 is sent or received
  through the local APIC, the APIC indicates an illegal vector in its
  Error Status Register (see Section 10.5.3, “Error Handling”).

and we support lowest-priority interrupts, because if we didn't, then

 The interrupt is not processed and hence the “Send Illegal Vector” bit
 is not set in the ESR.

I'll go for a quick bare-metal test ...