From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips Date: Wed, 04 Apr 2012 14:01:50 +0200 Message-ID: <4F7C382E.40009@siemens.com> References: <4F734EB3.20500@siemens.com> <4F748AAD.2040103@siemens.com> <4F74B484.30607@siemens.com> <4F7B24EA.2070300@redhat.com> <4F7B29B5.6060703@siemens.com> <20120404083821.GB3003@redhat.com> <4F7C09E7.3020005@redhat.com> <20120404085359.GA3404@redhat.com> <4F7C12E3.3050702@siemens.com> <4F7C161D.3090909@redhat.com> <4F7C16A4.6070303@siemens.com> <4F7C1A7A.5020902@redhat.com> <4F7C26F0.5090901@siemens.com> <4F7C3573.7080709@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , Marcelo Tosatti , kvm , Eric Northup To: Avi Kivity Return-path: Received: from goliath.siemens.de ([192.35.17.28]:30453 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756037Ab2DDMBz (ORCPT ); Wed, 4 Apr 2012 08:01:55 -0400 In-Reply-To: <4F7C3573.7080709@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-04-04 13:50, Avi Kivity wrote: > On 04/04/2012 01:48 PM, Jan Kiszka wrote: >>> >>> I'm not so sure anymore. Sorry about the U turn, but remind me why? In >>> the long term it will be slower. >> >> Likely not measurably slower. If you look at a message through the arch >> glasses, you can usually spot the destination directly, specifically if >> a message targets a single processor - no need for hashing and table >> lookups in the common case. > > Not on x86. The APIC ID is guest-provided. ...but is still a rather stable mapping on the physical ID. > In x2apic mode it can be > quite large. Yes, but then you can at least hash/search/cache inside that group only, with a smaller scope. > >> In contrast, the maintenance costs for the current explicit route based >> model are significant as we see now. >> > > You mean in amount of code in userspace? That doesn't get solved since > we need to keep compatibility. We do not need to track MSI origins to correlate them with routes (with the exception of 3 special devices: vhost-based virtio, kvm device assignment, and vfio device assignment). We emulate this centrally with a hand full of LOC in the kvm layer, and we bypass it with the advent of a direct injection API. Compare this to my original series that introduced MSIRoutingCaches to cope with the current kernel API. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux