From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips Date: Fri, 21 Oct 2011 14:04:44 +0200 Message-ID: <20111021120443.GB15360@redhat.com> References: <4EA13917.7070401@siemens.com> <20111021110608.GB14716@redhat.com> <4EA15CB3.2080904@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Marcelo Tosatti , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:29133 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754456Ab1JUMDk (ORCPT ); Fri, 21 Oct 2011 08:03:40 -0400 Content-Disposition: inline In-Reply-To: <4EA15CB3.2080904@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Oct 21, 2011 at 01:51:15PM +0200, Jan Kiszka wrote: > On 2011-10-21 13:06, Michael S. Tsirkin wrote: > > On Fri, Oct 21, 2011 at 11:19:19AM +0200, Jan Kiszka wrote: > >> Currently, MSI messages can only be injected to in-kernel irqchips by > >> defining a corresponding IRQ route for each message. This is not only > >> unhandy if the MSI messages are generated "on the fly" by user space, > >> IRQ routes are a limited resource that user space as to manage > >> carefully. > >> > >> By providing a direct injection with, we can both avoid using up limited > >> resources and simplify the necessary steps for user land. The API > >> already provides a channel (flags) to revoke an injected but not yet > >> delivered message which will become important for in-kernel MSI-X vector > >> masking support. > >> > >> Signed-off-by: Jan Kiszka > > > > I would love to see how you envision extending this to add the masking > > support at least at the API level, not necessarily the supporting code. > > > > It would seem hard to use flags field for that since MSIX mask is per > > device per vector, not per message. > > Which gets us back to resource per vector which userspace has to manage > > ... > > > > interrupt remapping is also per device, so it isn't any easier > > with this API. > > Yes, we will need an additional field to associate the message with its > source device. Could be a PCI address or a handle (like the one assigned > devices get) returned on MSI-X kernel region setup. We will need a flag > to declare that address/handle valid, also to tell apart platform MSI > messages (e.g. coming from HPET on x86). I have not thought about remapping a lot yet: HPET interrupts are not subject to remapping? > I see no obstacles ATM that > prevent doing that on top of this API, do you? > > Jan For masking, I think I do. We need to maintain the pending bit and the io notifiers in kernel, per vector. An MSI injected with just an address/data pair, without vector/device info, can't be masked properly. We get back to maintaining some handle per vector, right? > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux