From: Don Slutz <dslutz@verizon.com>
To: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Cc: Paul Durrant <paul.durrant@citrix.com>,
Don Slutz <dslutz@verizon.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: [Qemu-devel] [PATCH v2 0/4] Fix device listener interface for PCI to PCI bridges
Date: Mon, 8 Jun 2015 17:18:48 -0400 [thread overview]
Message-ID: <1433798332-5830-1-git-send-email-dslutz@verizon.com> (raw)
changes v1 to v2:
Split v1 patch into 3.
Added a BUG FIX patch (#1: "exec: Do not use MemoryRegion after
free").
Technically this bug fix should be a separate patch, however this
issue only seems to reproduce when this patch set is applied.
Michael S. Tsirkin:
"You need some other API that makes sense, probably PCI specific."
This is basically patch #2: "Extend device listener interface..."
"This is relying on undocumented assumptions and how specific
firmware works. There's nothing special about bus number 255,
and 0 is not very special either (except it happens to be the
reset value)."
Dropped all checking of 0 and 255.
Open question by Michael S. Tsirkin:
>>>> On Thu, May 28, 2015 at 07:25:50AM -0400, Don Slutz wrote:
...
>>>> It is not clear to me that the complexity of tracking bus
>>>> visibility make sense. Clearly you do.
>>> Well what was the point of the change?
>
> To get config cycles that are valid that you do not get today.
>
>>> If you don't care that we get irrelevant config cycles why not
>>> just send them all to QEMU?
>>>
>
> That would need to be answered by Paul Durrant and/or other people (see
> below)
>
We could broadcast config space ioreqs to all emulators, the problem
is how do we know (in the case of a read) which emulator is actually
the one supplying the data? At some level Xen needs to know who is
implementing what.
Paul Durrant
So this patch set just adjusts Xen to correctly know the current set
of PCI devices and their bus, device, and function.
It does not attempt to calculate the visibility of the PCI devices.
v1:
Note: Right now hvmloader in Xen does not handle PCI to PCI bridges
and so SeaBIOS does not have access to PCI device(s) on secondary
buses. How ever domU can setup the secondary bus(es) and this patch
will restore access to these PCI devices.
Don Slutz (4):
exec: Do not use MemoryRegion after free
Extend device listener interface for PCI to PCI bridges
xen: Add usage of device listener interface for PCI to PCI bridges
xen: Fix map/unmap of pcidev to ioreq server
exec.c | 8 ++++--
hw/core/qdev.c | 7 ++++++
hw/pci/pci_bridge.c | 18 +++++++++++++
include/hw/qdev-core.h | 3 +++
include/hw/xen/xen_common.h | 61 ++++++++++++++++++++++++++++++++++-----------
trace-events | 6 +++--
xen-hvm.c | 20 +++++++++++++--
7 files changed, 102 insertions(+), 21 deletions(-)
--
1.8.4
next reply other threads:[~2015-06-08 21:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 21:18 Don Slutz [this message]
2015-06-08 21:18 ` [Qemu-devel] [BUGFIX][PATCH v2 1/4] exec: Do not use MemoryRegion after free Don Slutz
2015-06-08 21:18 ` [Qemu-devel] [PATCH v2 2/4] Extend device listener interface for PCI to PCI bridges Don Slutz
2015-06-09 9:08 ` Paul Durrant
2015-06-09 13:53 ` Don Slutz
2015-06-09 13:55 ` Paul Durrant
2015-06-09 14:00 ` Don Slutz
2015-06-08 21:18 ` [Qemu-devel] [PATCH v2 3/4] xen: Add usage of " Don Slutz
2015-06-08 21:18 ` [Qemu-devel] [PATCH v2 4/4] xen: Fix map/unmap of pcidev to ioreq server Don Slutz
2015-06-09 9:05 ` Paul Durrant
2015-06-09 13:51 ` Don Slutz
2015-06-09 14:03 ` Paul Durrant
2015-06-09 14:28 ` Don Slutz
2015-06-09 15:11 ` Paul Durrant
2015-06-09 16:40 ` Don Slutz
2015-06-09 9:13 ` [Qemu-devel] [PATCH v2 0/4] Fix device listener interface for PCI to PCI bridges Michael S. Tsirkin
2015-06-09 9:18 ` Paul Durrant
2015-06-09 10:52 ` Michael S. Tsirkin
2015-06-09 10:58 ` Paul Durrant
2015-06-09 12:29 ` Michael S. Tsirkin
2015-06-09 14:14 ` Paul Durrant
2015-06-09 14:27 ` Michael S. Tsirkin
2015-06-09 15:10 ` Don Slutz
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=1433798332-5830-1-git-send-email-dslutz@verizon.com \
--to=dslutz@verizon.com \
--cc=mst@redhat.com \
--cc=paul.durrant@citrix.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.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).