From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756383AbcAZBol (ORCPT ); Mon, 25 Jan 2016 20:44:41 -0500 Received: from mail-pa0-f66.google.com ([209.85.220.66]:35872 "EHLO mail-pa0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbcAZBoj (ORCPT ); Mon, 25 Jan 2016 20:44:39 -0500 Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination To: "rkrcmar@redhat.com" References: <56A065B3.4020202@gmail.com> <56A06E3A.7050804@gmail.com> <56A0703D.3060701@gmail.com> <20160121163545.GA17514@potion.brq.redhat.com> <56A18DE4.80808@gmail.com> <20160122133144.GE17514@potion.brq.redhat.com> <56A57F41.90108@gmail.com> <20160125135928.GA21252@potion.brq.redhat.com> Cc: "Wu, Feng" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" From: Yang Zhang Message-ID: <56A6CF81.9070008@gmail.com> Date: Tue, 26 Jan 2016 09:44:33 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160125135928.GA21252@potion.brq.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/1/25 21:59, rkrcmar@redhat.com wrote: > 2016-01-25 09:49+0800, Yang Zhang: >> On 2016/1/22 21:31, rkrcmar@redhat.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