All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
Date: Fri, 21 Oct 2011 14:04:44 +0200	[thread overview]
Message-ID: <20111021120443.GB15360@redhat.com> (raw)
In-Reply-To: <4EA15CB3.2080904@siemens.com>

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 <jan.kiszka@siemens.com>
> > 
> > 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

  reply	other threads:[~2011-10-21 12:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-21  9:19 [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips Jan Kiszka
2011-10-21  9:42 ` Sasha Levin
2011-10-21 11:06 ` Michael S. Tsirkin
2011-10-21 11:51   ` Jan Kiszka
2011-10-21 12:04     ` Michael S. Tsirkin [this message]
2011-10-21 13:00       ` Jan Kiszka
2011-10-24  9:45 ` Avi Kivity
2011-10-24 10:19   ` Jan Kiszka
2011-10-24 11:09     ` Avi Kivity
2011-10-24 12:06       ` Jan Kiszka
2011-10-24 12:43         ` Michael S. Tsirkin
2011-10-24 13:11           ` Jan Kiszka
2011-10-24 13:43             ` Jan Kiszka
2011-10-24 14:40               ` Michael S. Tsirkin
2011-10-24 15:00                 ` Jan Kiszka
2011-10-24 16:05                   ` Michael S. Tsirkin
2011-10-24 16:10                     ` Jan Kiszka
2011-10-24 17:05                       ` Michael S. Tsirkin
2011-10-24 17:23                         ` Michael S. Tsirkin
2011-10-25  7:24                           ` Jan Kiszka
2011-10-25 11:20                             ` Michael S. Tsirkin
2011-10-25 11:41                               ` Jan Kiszka
2011-10-25 12:05                                 ` Michael S. Tsirkin
2011-10-25 12:21                                   ` Jan Kiszka
2011-10-25 13:29                                     ` Michael S. Tsirkin
2011-10-24 14:25             ` Michael S. Tsirkin
2011-10-25  7:56         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111021120443.GB15360@redhat.com \
    --to=mst@redhat.com \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.