qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Carsten Otte <cotte@de.ibm.com>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	virtualization@lists.linux-foundation.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api
Date: Thu, 21 May 2009 13:29:37 +0100	[thread overview]
Message-ID: <200905211329.41578.paul@codesourcery.com> (raw)
In-Reply-To: <4A154432.1060808@redhat.com>

On Thursday 21 May 2009, Avi Kivity wrote:
> Paul Brook wrote:
> >>>> In any case we need some internal API for this, and qemu_irq looks
> >>>> like a good choice.
> >>>
> >>> What do you expect to be using this API?
> >>
> >> virtio, emulated devices capable of supporting MSI (e1000?), device
> >> assignment (not yet in qemu.git).
> >
> > It probably makes sense to have common infrastructure in pci.c to
> > expose/implement device side MSI functionality. However I see no need for
> > a direct API between the device and the APIC. We already have an API for
> > memory accesses and MMIO regions. I'm pretty sure a system could
> > implement MSI by pointing the device at system ram, and having the CPU
> > periodically poll that.
>
> Instead of writing directly, let's abstract it behind a qemu_set_irq().
> This is easier for device authors.  The default implementation of the
> irq callback could write to apic memory, while for kvm we can directly
> trigger the interrupt via the kvm APIs.

I'm still not convinced.

A tight coupling between PCI devices and the APIC is just going to cause us 
problems later one. I'm going to come back to the fact that these are memory 
writes so once we get IOMMU support they will presumably be subject to 
remapping by that, just like any other memory access.

Even ignoring that, qemu_irq isn't really the right interface. A MSI is a one-
off event, not a level state. OTOH stl_phys is exactly the right interface.

The KVM interface should be contained within the APIC implementation.

Paul

  parent reply	other threads:[~2009-05-21 12:29 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-20 16:21 [Qemu-devel] [PATCH] qemu: msi irq allocation api Michael S. Tsirkin
2009-05-20 17:21 ` Blue Swirl
2009-05-20 17:32   ` Avi Kivity
2009-05-20 17:40     ` Blue Swirl
2009-05-20 17:35   ` Michael S. Tsirkin
2009-05-20 17:44     ` Blue Swirl
2009-05-20 18:24       ` Michael S. Tsirkin
2009-05-20 18:28       ` Michael S. Tsirkin
2009-05-20 18:38         ` Blue Swirl
2009-05-20 20:02           ` Michael S. Tsirkin
2009-05-20 20:17             ` Michael S. Tsirkin
2009-05-20 20:26               ` Blue Swirl
2009-05-20 20:33                 ` Michael S. Tsirkin
2009-05-20 20:44                   ` Blue Swirl
2009-05-21  9:24                     ` Michael S. Tsirkin
2009-05-20 20:18             ` Blue Swirl
2009-05-20 20:29               ` Michael S. Tsirkin
2009-05-21 10:09 ` Paul Brook
2009-05-21 10:23   ` Avi Kivity
2009-05-21 10:34     ` Paul Brook
2009-05-21 10:50       ` Michael S. Tsirkin
2009-05-21 11:01       ` Avi Kivity
2009-05-21 12:01         ` Paul Brook
2009-05-21 12:08           ` Avi Kivity
2009-05-21 12:14             ` Michael S. Tsirkin
2009-05-21 12:29             ` Paul Brook [this message]
2009-05-21 12:38               ` Avi Kivity
2009-05-21 13:08                 ` Michael S. Tsirkin
2009-05-21 13:09                 ` Paul Brook
2009-05-21 13:12                   ` Michael S. Tsirkin
2009-05-21 13:23                     ` Paul Brook
2009-05-21 13:31                       ` Paul Brook
2009-05-21 16:45                         ` Michael S. Tsirkin
2009-05-21 17:33                           ` Michael S. Tsirkin
2009-05-21 13:46                       ` Michael S. Tsirkin
2009-05-21 13:53                         ` Paul Brook
2009-05-21 14:01                           ` Avi Kivity
2009-05-21 14:14                             ` Paul Brook
2009-05-21 14:37                               ` Avi Kivity
2009-05-21 14:50                                 ` Paul Brook
2009-05-21 14:54                                   ` Avi Kivity
2009-05-21 15:01                                     ` Paul Brook
2009-05-21 15:11                                       ` Avi Kivity
2009-05-21 16:49                                   ` Michael S. Tsirkin
2009-05-21 14:07                           ` Michael S. Tsirkin
2009-05-24 11:14                             ` Avi Kivity
2009-05-21 14:46                       ` Michael S. Tsirkin
2009-05-21 13:11                 ` Michael S. Tsirkin
2009-05-21 13:06               ` Michael S. Tsirkin

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=200905211329.41578.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=avi@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).