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: <56A6CF81.9070008@gmail.com>
Date:	Tue, 26 Jan 2016 09:44:33 +0800
From:	Yang Zhang <yang.zhang.wz@...il.com>
To:	"rkrcmar@...hat.com" <rkrcmar@...hat.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

On 2016/1/25 21:59, rkrcmar@...hat.com wrote:
> 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.)

Sorry for my poor english. :(

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

This is what KVM does currently.

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

Also, most part of work is covered by current logic except checking the 
multicast.

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

Do you mean per vcpu posted interrupts?

> interrupts is the fastest way to distinguish the interrupt source.

-- 
best regards
yang