From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips Date: Tue, 25 Oct 2011 09:24:17 +0200 Message-ID: <4EA66421.9060100@siemens.com> References: <4EA54759.902@redhat.com> <4EA554B0.7030808@siemens.com> <20111024124355.GA28822@redhat.com> <4EA563FD.5060308@siemens.com> <4EA56B99.2030201@siemens.com> <20111024144039.GB29886@redhat.com> <4EA57D8B.7020905@siemens.com> <20111024160526.GA30385@redhat.com> <4EA58DF4.2050100@siemens.com> <20111024170508.GB30385@redhat.com> <20111024172311.GC30385@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Marcelo Tosatti , kvm To: "Michael S. Tsirkin" Return-path: Received: from goliath.siemens.de ([192.35.17.28]:34210 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754954Ab1JYHYX (ORCPT ); Tue, 25 Oct 2011 03:24:23 -0400 In-Reply-To: <20111024172311.GC30385@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-10-24 19:23, Michael S. Tsirkin wrote: > On Mon, Oct 24, 2011 at 07:05:08PM +0200, Michael S. Tsirkin wrote: >> On Mon, Oct 24, 2011 at 06:10:28PM +0200, Jan Kiszka wrote: >>> On 2011-10-24 18:05, Michael S. Tsirkin wrote: >>>>> This is what I have in mind: >>>>> - devices set PBA bit if MSI message cannot be sent due to mask (*) >>>>> - core checks&clears PBA bit on unmask, injects message if bit was set >>>>> - devices clear PBA bit if message reason is resolved before unmask (*) >>>> >>>> OK, but practically, when exactly does the device clear PBA? >>> >>> Consider a network adapter that signals messages in a RX ring: If the >>> corresponding vector is masked while the guest empties the ring, I >>> strongly assume that the device is supposed to take back the pending bit >>> in that case so that there is no interrupt inject on a later vector >>> unmask operation. >>> >>> Jan >> >> Do you mean virtio here? Maybe, but I'm also thinking of fully emulated devices. > Do you expect this optimization to give >> a significant performance gain? Hard to asses in general. But I have a silly guest here that obviously masks MSI vectors for each event. This currently not only kicks us into a heavy-weight exit, it also enforces serialization on qemu_global_mutex (while we have the rest already isolated). > > It would also be challenging to implement this in > a race free manner. Clearing on interrupt status read > seems straight-forward. With an in-kernel MSI-X MMIO handler, this race will be naturally unavoidable as there is no more global lock shared between table/PBA accesses and the device model. But, when using atomic bit ops, I don't think that will cause headache. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux