All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: peter.maydell@linaro.org, jasowang@redhat.com,
	qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 2/2] pci: add PCIIOMMUOps and PCIIOMMUIntRemapFunc
Date: Thu, 18 Feb 2016 12:54:18 +0800	[thread overview]
Message-ID: <20160218045418.GA5411@pxdev.xzpeter.org> (raw)
In-Reply-To: <56C4CE0A.4070501@redhat.com>

On Wed, Feb 17, 2016 at 08:46:18PM +0100, Paolo Bonzini wrote:
> 
> 
> On 17/02/2016 11:25, Peter Xu wrote:
> > This patch extended the current PCI IOMMU functions into operation list,
> > one new op is added to do interrupt remapping.
> > 
> > Currently it is not working since int_remap is always NULL. It only
> > provide a interface to extend PCI MSI to support interrupt remapping in
> > the future.
> > 
> > One helper function pci_setup_iommu_ops() is introduced. We can use this
> > instead of the origin pci_setup_iommu() one to extend interrupt
> > remapping on specific platform.
> 
> For MSI, I think interrupt remapping can be done directly in the IOMMU
> MemoryRegion.  You can just overlay a new MemoryRegion on top of the
> IOMMU region where MSIs are sent (that's around 0xFEE00000, I don't
> remember where exactly).  It will catch interrupts sent by the device,
> remap them and forward them to the right interrupt destination in the host.

Yes, it should be 0xfee00000. I'd say this is a much better idea, so
that I can leverage current memory region codes and avoid touching
PCI at all.

If the work is in iommu part, I think I can send my next RFC with
basic IR together next time.

> 
> I'm not sure about INTX interrupts, but I think that the host kernel
> remaps them simply by virtualizing the IOAPIC's redirection table.

Yes, what I understand is that, IOAPIC is handling all INTX
interrupts. To remap these interrupts, we just need a translation
for the IOAPIC IRQ table entries before the interrupts are delivered
to APIC bus.

There will need some code change in ACPI too to enumerate the IOAPIC
device in DMAR region, so that we can declare that "this IOMMU owns
the default IOAPIC".

If so, I can call vtd_* function in ioapic_service() directly right?
IIUC IOAPIC should be intel-specific too?

Thanks!
Peter

> 
> Paolo

      reply	other threads:[~2016-02-18  4:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17 10:25 [Qemu-devel] [RFC PATCH 0/2] Add one more PCI IOMMU ops Peter Xu
2016-02-17 10:25 ` [Qemu-devel] [RFC PATCH 1/2] pci: renaming PCIIOMMUFunc to PCIIOMMUASLookupFunc Peter Xu
2016-02-17 10:25 ` [Qemu-devel] [RFC PATCH 2/2] pci: add PCIIOMMUOps and PCIIOMMUIntRemapFunc Peter Xu
2016-02-17 19:46   ` Paolo Bonzini
2016-02-18  4:54     ` Peter Xu [this message]

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=20160218045418.GA5411@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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 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.