qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net,
	ehabkost@redhat.com, jasowang@redhat.com, marcel@redhat.com,
	mst@redhat.com, pbonzini@redhat.com, rkrcmar@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 12/13] intel_iommu: ioapic: IR support for emulated IOAPIC
Date: Wed, 13 Apr 2016 11:33:04 +0800	[thread overview]
Message-ID: <20160413033304.GB17558@pxdev.xzpeter.org> (raw)
In-Reply-To: <570D1696.2080301@web.de>

On Tue, Apr 12, 2016 at 08:39:02AM -0700, Jan Kiszka wrote:
> On 2016-04-12 02:02, Peter Xu wrote:

[...]

> > Yes, I should consider other x86 platforms like AMD. Thanks to point
> > out. It seems that there are many places in the patchset that lacks
> > thorough consideration about this. Will try to fix them in next
> > version.
> > 
> > Regarding to the above MSI solution: I'd say it is a good way to
> > hide everything else behind.  However, since we introduced one extra
> > layer (MSI) which actually does not exist, not sure there would be
> > problem too.  Also, I feel it a little bit hacky if we "create" one
> > MSI out of the air...  For example, if someone tries to capture MSIs
> > from QEMU inside in the APIC memory writes, he will see something he
> > cannot explain if he never knows this hack's there.  Considering the
> > above, I would prefer hooks, or better to provide a callback (a
> > function pointer that others like AMD can override) to do the
> > translation.  How do you think?
> 
> The HPET does send MSIs, and I'm not sure how much different the
> IOAPIC's message actually is. In any case, modelling it as MSI is
> neither adding incorrectness nor making the code more complex (in fact,
> the contrary is true!). Last but not least, it would be trivial to
> filter out non-PCI MSI sources if we wanted to trace only PCI - because
> we need to identify the origin anyway for remapping purposes. So,
> explicit hooking looks like the wrong way to me.

I am just not sure about the difference between IOAPIC's messages
and MSI ones. For now, they seems very alike. However, I am not sure
whether it would be not alike in the future. E.g., if one day, we
extend APIC bus to support more than 255 CPUs (could it? I do not
know for sure), here if we are with this "MSI layer", we would not
be able to do that, since MSI only support 8 bits for destination ID
field. That's my only worry now. If you (or Radim? or anyone more
experienced on this than me) can confirm that this would never be a
problem, I'd be glad to take the MSI way.

Thanks.

-- peterx

  reply	other threads:[~2016-04-13  3:33 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-11  9:19 [Qemu-devel] [PATCH v2 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 01/13] q35: add "int-remap" flag to enable intr Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 02/13] acpi: enable INTR for DMAR report structure Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 03/13] intel_iommu: allow queued invalidation for IR Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 04/13] intel_iommu: set IR bit for ECAP register Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 05/13] acpi: add DMAR scope definition for root IOAPIC Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 06/13] intel_iommu: define interrupt remap table addr register Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 07/13] intel_iommu: handle interrupt remap enable Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 08/13] intel_iommu: define several structs for IOMMU IR Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 09/13] intel_iommu: provide helper function vtd_get_iommu Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 10/13] ioapic-common: add iommu for IOAPICCommonState Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 11/13] intel_iommu: add IR translation faults defines Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 12/13] intel_iommu: ioapic: IR support for emulated IOAPIC Peter Xu
2016-04-12  5:22   ` Jan Kiszka
2016-04-12  9:02     ` Peter Xu
2016-04-12 15:39       ` Jan Kiszka
2016-04-13  3:33         ` Peter Xu [this message]
2016-04-13  3:39           ` Jan Kiszka
2016-04-13  5:09             ` Peter Xu
2016-04-13 10:06             ` Peter Xu
2016-04-13 14:44               ` Jan Kiszka
2016-04-14  2:46                 ` Peter Xu
2016-04-14  5:42                   ` Jan Kiszka
2016-04-14  8:28                     ` Peter Xu
2016-04-11  9:19 ` [Qemu-devel] [PATCH v2 13/13] intel_iommu: Add support for PCI MSI remap Peter Xu
2016-04-11 12:41   ` Michael S. Tsirkin
2016-04-13  7:23     ` Peter Xu
2016-04-11 12:32 ` [Qemu-devel] [PATCH v2 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU Michael S. Tsirkin
2016-04-13  7:27   ` Peter Xu
2016-04-13 14:39     ` Jan Kiszka
2016-04-14  5:25       ` Peter Xu
2016-04-11 22:19 ` Alex Williamson
2016-04-13  7:37   ` Peter Xu

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=20160413033304.GB17558@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jan.kiszka@web.de \
    --cc=jasowang@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkrcmar@redhat.com \
    --cc=rth@twiddle.net \
    /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).