From: Peter Xu <peterx@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Marcel Apfelbaum <marcel@redhat.com>,
qemu-devel@nongnu.org, ehabkost@redhat.com, mst@redhat.com,
jasowang@redhat.com, imammedo@redhat.com, pbonzini@redhat.com,
rth@twiddle.net, Rita Sinha <rita.sinha89@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 05/13] acpi: add DMAR scope definition for root IOAPIC
Date: Fri, 8 Apr 2016 17:53:52 +0800 [thread overview]
Message-ID: <20160408095352.GC26923@pxdev.xzpeter.org> (raw)
In-Reply-To: <56C9DF3E.4060907@web.de>
On Sun, Feb 21, 2016 at 05:01:02PM +0100, Jan Kiszka wrote:
> >> We have the same problem over with VT-d and IR.
> >>
> >> I don't think the firmware is not the right place, otherwise there would
> >> be an interface in hw to adjust that parameters. I think we should
> >> simply make sure that the qemu user cannot assign devices to those
> >> addresses as they are reserved for the platform devices (the HPET
> >> requires another ID), or even reserve the hole bus for the platform.
> >
> >
> > I understand, but it is the firmware that assign addresses, not QEMU/user.
>
> Right, buses are chosen by the firmware, but device address are
> (optionally) under user control.
>
> > We need a way to tell the firmware not to use a certain address range,
> > we can do that
> > with fw_config I suppose.
>
> The pseudo addresses of IOAPIC and HPET are part of ACPI tables, both on
> AMD and Intel. Firmware can evaluate them easily.
Hi, Jan, Marcel,
Could you give me some hint on how to achieve this using fw_config
(restriction on PCI bus numbers)? I failed to find it out myself.
Thanks in advance.
-- peterx
next prev parent reply other threads:[~2016-04-08 9:54 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 3:30 [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 01/13] q35: add "int-remap" flag to enable intr Peter Xu
2016-02-21 10:38 ` Marcel Apfelbaum
2016-02-23 3:48 ` Peter Xu
2016-02-25 15:47 ` Marcel Apfelbaum
2016-04-08 7:30 ` Peter Xu
2016-04-11 10:07 ` Marcel Apfelbaum
2016-02-19 3:30 ` [Qemu-devel] [PATCH 02/13] acpi: enable INTR for DMAR report structure Peter Xu
2016-02-21 11:05 ` Marcel Apfelbaum
2016-04-08 8:07 ` Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 03/13] intel_iommu: allow queued invalidation for IR Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 04/13] intel_iommu: set IR bit for ECAP register Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 05/13] acpi: add DMAR scope definition for root IOAPIC Peter Xu
2016-02-21 11:38 ` Marcel Apfelbaum
2016-02-21 12:08 ` Marcel Apfelbaum
2016-02-21 13:40 ` Jan Kiszka
2016-02-21 15:54 ` Marcel Apfelbaum
2016-02-21 16:01 ` Jan Kiszka
2016-04-08 9:53 ` Peter Xu [this message]
2016-02-19 3:30 ` [Qemu-devel] [PATCH 06/13] intel_iommu: define interrupt remap table addr register Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 07/13] intel_iommu: handle interrupt remap enable Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 08/13] intel_iommu: define several structs for IOMMU IR Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 09/13] intel_iommu: provide helper function vtd_get_iommu Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 10/13] ioapic-common: add iommu for IOAPICCommonState Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 11/13] intel_iommu: add IR translation faults defines Peter Xu
2016-02-21 15:56 ` Marcel Apfelbaum
2016-04-08 10:03 ` Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 12/13] intel_iommu: ioapic: IR support for emulated IOAPIC Peter Xu
2016-02-19 3:30 ` [Qemu-devel] [PATCH 13/13] intel_iommu: Add support for PCI MSI remap Peter Xu
2016-02-19 6:46 ` [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU Jan Kiszka
2016-02-19 7:43 ` Peter Xu
2016-02-19 8:34 ` Jan Kiszka
2016-02-19 9:29 ` Peter Xu
2016-02-19 9:58 ` Paolo Bonzini
2016-02-19 10:15 ` Jan Kiszka
2016-02-19 11:39 ` Peter Xu
2016-02-19 11:43 ` Jan Kiszka
2016-02-19 11:34 ` Peter Xu
2016-02-19 11:43 ` Jan Kiszka
2016-02-19 16:22 ` Radim Krčmář
2016-02-20 10:05 ` Jan Kiszka
2016-02-19 16:38 ` Radim Krčmář
2016-02-23 5:03 ` 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=20160408095352.GC26923@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=rita.sinha89@gmail.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).