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
next prev parent 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).