linux-kernel - Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination

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: <20160125135928.GA21252@potion.brq.redhat.com>
Date:	Mon, 25 Jan 2016 14:59:28 +0100
From:	"rkrcmar@...hat.com" <rkrcmar@...hat.com>
To:	Yang Zhang <yang.zhang.wz@...il.com>
Cc:	"Wu, Feng" <feng.wu@...el.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the
 interrupt is not single-destination

2016-01-25 09:49+0800, Yang Zhang:
> On 2016/1/22 21:31, rkrcmar@...hat.com wrote:
>>2016-01-22 10:03+0800, Yang Zhang:
>>>Not so complicated. We can reuse the wake up vector and check whether the
>>>interrupt is multicast when one of destination vcpu handles it.
>>
>>I'm not sure what you mean now ... I guess it is:
>>- Deliver the interrupt to a guest VCPU and relay the multicast to other
>>   VCPUs.  No, it's strictly worse than intercepting it in the host.
> 
> It is still handled in host context not guest context. The wakeup event
> cannot be consumed like posted event.

Ok.  ("when one of destination vcpu handles it" confused me into
thinking that you'd like to handle it with the notification vector.)

>                                       So it relies on hypervisor to inject
> the interrupt to guest. We can add the check at this point.

Yes, but I don't think we want to do that, because of following
drawbacks:

>>- Modify host's wakeup vector handler to send the multicast.
>>   It's so complicated, because all information you start with in the
>>   host is a vector number.  You start with no idea what the multicast
>>   interrupt should be.
>>
>>   We could add per-multicast PID to the list of parsed PIDs in
>>   wakeup_handler and use PID->multicast interrupt mapping to tell which
>>   interrupt we should send, but that seems worse than just delivering a
>>   non-remapped interrupt.

(should have been "remapped, but non-posted".)

>>   Also, if wakeup vector were used for wakeup and multicast, we'd be
>>   uselessly doing work, because we can't tell which reason triggered the
>>   interrupt before finishing one part -- using separate vectors for that
>>   would be a bit nicer.

(imprecise -- we would always have to check for ON bit of all PIDs from
 blocked VCPUs, for the original meaning of wakeup vector, and always
 either read the PIRR or check for ON bit of all PIDs that encode
 multicast interrupts;  then we have to clear ON bits for multicasts.)


---
There might be a benefit of using posted interrupts for host interrupts
when we run out of free interrupt vectors:  we could start using vectors
by multiple sources through posted interrupts, if using posted
interrupts is the fastest way to distinguish the interrupt source.