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: <20151222195259.GC12725@potion.redhat.com>
Date:	Tue, 22 Dec 2015 20:52:59 +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-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:
>> >>>>>>> +				for_each_set_bit(i, &bitmap, 16) {
>> >>>>>>> +					if (!dst[i]
>> >>>>>> && !kvm_lapic_enabled(dst[i]->vcpu)) {
>> >>>>>>
>> >>>>>> It should be or(||) not and (&&).
>> >>>>>
>> >>>>> Oh, you are right! My negligence! Thanks for pointing this out, Yang!
>> >>>>
>> >>>> btw, i think the kvm_lapic_enabled check is wrong here? Why need it here?
>> >>>
>> >>> If the lapic is not enabled, I think we cannot recognize it as a candidate, can
>> >> we?
>> >>> Maybe Radim can confirm this, Radim, what is your option?

SDM 10.6.2.2 Logical Destination Mode:
  For both configurations of logical destination mode, when combined
  with lowest priority delivery mode, software is responsible for
  ensuring that all of the local APICs included in or addressed by the
  IPI or I/O subsystem interrupt are present and enabled to receive the
  interrupt.

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"))

(v1 was arguable better, I pointed the need for enabled LAPIC in v1 only
 from looking at one KVM function, sorry.)

>> >> Lapic can be disable by hw or sw. Here we only need to check the hw is
>> >> enough which is already covered while injecting the interrupt into
>> >> guest. I remember we(Glab, Macelo and me) have discussed it several ago,
>> >> but i cannot find the mail thread.
>>
>> >
>> > But if the lapic is disabled by software, we cannot still inject interrupts to
>> > it, can we?
>> 
>> Yes, We cannot inject the normal interrupt. But this already covered by
>> current logic and add a check here seems meaningless. Conversely, it may
>> do bad thing..
>> 
> 
> Let's wait for Radim/Paolo's opinions about this.

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 :)

I'll review the series tomorrow, thanks for your patience.
--
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/