linux-kernel - Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts

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: <20151223164217.GD12725@potion.redhat.com>
Date:	Wed, 23 Dec 2015 17:42:17 +0100
From:	"rkrcmar@...hat.com" <rkrcmar@...hat.com>
To:	"Wu, Feng" <feng.wu@...el.com>
Cc:	Yang Zhang <yang.zhang.wz@...il.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Jiang Liu (jiang.liu@...ux.intel.com)" <jiang.liu@...ux.intel.com>
Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver
 lowest-priority interrupts

2015-12-23 02:12+0000, Wu, Feng:
>> From: rkrcmar@...hat.com [mailto:rkrcmar@...hat.com]
>> 2015-12-22 07:19+0000, Wu, Feng:
>> >> From: Yang Zhang [mailto:yang.zhang.wz@...il.com]
>> >> On 2015/12/22 14:59, Wu, Feng wrote:
>> >> >> From: Yang Zhang [mailto:yang.zhang.wz@...il.com]
>> >> >>>>>> On 2015/12/16 9:37, Feng Wu wrote:
>> The case is undefined if some targeted LAPICs weren't hardware enabled
>> as no interrupts can be delivered to hardware disabled LAPIC, so we can
>> check for hardware enabled.
>> 
>> It's not obvious if "enabled to receive the interrupt" means hardware or
>> software enabled, but lowest priority cannot deliver NMI/INIT/..., so
>> checking for software enabled doesn't restrict any valid uses either.
>> 
>> so ... KVM only musn't blow up when encountering this situation :)
>> 
>> The current code seems correct, but redundant.  Just for reference, KVM
>> now does:
>> - check for software enabled LAPIC since patch aefd18f01ee8 ("KVM: x86:
>>   In DM_LOWEST, only deliver interrupts to vcpus with enabled LAPIC's")
>> - check only for hardware enabled LAPIC in the fast path, since
>>   1e08ec4a130e ("KVM: optimize apic interrupt delivery"))
> 
> Software enabled LAPIC is also checked in patch 1e08ec4a130e
> ("KVM: optimize apic interrupt delivery"), however, it was removed
> in patch 3b5a5ffa928a3f875b0d5dd284eeb7c322e1688a.

Right, thanks.  (The software check was actually removed in 173beedc1601
("KVM: x86: Software disabled APIC should still deliver NMIs"), which
introduced a two pass mechanism that was later simplified.)

>                                                    Now I am
> a little confused about the policy, when and where should we do
> the software/hardware enabled check?

It's a mess, I think we'd like both checks to be done early and ideally
only in one place.

The fast path would like to precompute as much as possible, but only
hardware enabled affects all interrupts (like non-present LAPIC);
software disabled still needs an extra condition for every interrupt.

>> I'd pick whatever results in less code: this time it seems like checking
>> for hardware enabled LAPIC in both paths (implicitly in the fast path).
>> Maybe it can be done better, I haven't given it much thought.
>> 
>> We should revert aefd18f01ee8 at the same time, so our PI/non-PI slow
>> paths won't diverge -- I hope it wasn't fixing a bug :)
> 
> From the change log, It seems to me this patch was fixing a bug.

Yeah, I found the original discussion
  RFC: http://www.spinics.net/lists/kvm/msg36190.html
  v1:  http://www.spinics.net/lists/kvm/msg36395.html
  v2:  http://www.spinics.net/lists/kvm/msg36651.html

that led to some explanation in bugzilla:
  https://bugzilla.redhat.com/show_bug.cgi?id=596223 (a clone of
  https://bugzilla.redhat.com/show_bug.cgi?id=505527)

It seems that kexec on VCPU != 0 did something with BSP APIC ID that
resulted in a wrong delivery -- I didn't look where the bug was, but the
solution we adopted is probably just a lucky workaround.
Makes sense to look deeper into it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/