From: "Michael S. Tsirkin" <mst@redhat.com>
To: qemu-devel@nongnu.org, kvm@vger.kernel.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Isaku Yamahata <yamahata@valinux.co.jp>,
Avi Kivity <avi@redhat.com>,
kraxel@redhat.com
Subject: [PATCHv3 0/4] standard pci bridge device
Date: Tue, 21 Feb 2012 00:52:46 +0200 [thread overview]
Message-ID: <cover.1329778092.git.mst@redhat.com> (raw)
Here's a new version of the patch.
TODOs:
- windows guest testing
Changes from v2:
- added slot id capability
- migration support
- misc fixes
- fix checkpatch errors
I also include a patch to make all bridges have a user-friendly id.
You don't absolutely have to have it for testing,
but this makes use easier. Without it, you must replace
bus=<id> in instructions below with bus=<id>.0
(add ".0" literally after the id).
Changes from v1:
- hotplug support
Status: tested with a linux guest on x86.
Deep nesting of bridges is supported.
You need a small BIOS patch to support the OSHP method
if you want hotplug to work. Posted separately.
We'd need a full ACPI driver to make hotplug work for guests
without an SHPC driver (e.g. windows XP).
Management support will also be needed.
One small wrinkle is that the pci_addr property
used for pci_add command wants data in a format
bus:device.function which is
broken as guests can change bus numbers.
I don't intend to fix it short term.
So, don't use the pci_add command.
Only device_add works with a bridge.
(Side note: the 'addr' property
encodes slot*8+function#. It is not user-friendly.
Let's add optional slot= func= ?)
The SHPC controller supports up to 31 devices
(out of 32 slots) so slot 0 doesn't support hotplug.
Non hot-pluggable devices behind the bridge
don't work currectly (we'll try to unplug them)
so don't do this.
For now I just blocked adding devices in slot 0,
in the future it might be possible to add
a non-hotpluggable device there.
Each bridge must have a unique chassis #.
You *must* set it to a value > 0.
I don't check that it is unique, just that it is >0.
If you make it non unique, guest will be confused.
Example:
qemu-system-x86_64 -enable-kvm -m 1G
-drive file=/home/mst/rhel6.qcow2
-netdev
tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on
-device pci-bridge,id=bog,chassis_nr=1
-device virtio-net-pci,netdev=foo,bus=bog,addr=8
Hot-unplug currently causes qemu to crash, this
happens without this patch too, so I'm not worried :)
Michael S. Tsirkin (4):
pci_bridge: user-friendly default bus name
shpc: standard hot plug controller
slotid: add slot id capability
pci: add standard bridge device
Makefile.objs | 4 +-
hw/pci.h | 8 +
hw/pci_bridge.c | 10 +
hw/pci_bridge_dev.c | 151 ++++++++++++
hw/shpc.c | 673 +++++++++++++++++++++++++++++++++++++++++++++++++++
hw/shpc.h | 45 ++++
hw/slotid_cap.c | 44 ++++
hw/slotid_cap.h | 11 +
qemu-common.h | 1 +
9 files changed, 946 insertions(+), 1 deletions(-)
create mode 100644 hw/pci_bridge_dev.c
create mode 100644 hw/shpc.c
create mode 100644 hw/shpc.h
create mode 100644 hw/slotid_cap.c
create mode 100644 hw/slotid_cap.h
--
1.7.9.111.gf3fb0
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: qemu-devel@nongnu.org, kvm@vger.kernel.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Isaku Yamahata <yamahata@valinux.co.jp>,
Avi Kivity <avi@redhat.com>,
kraxel@redhat.com
Subject: [Qemu-devel] [PATCHv3 0/4] standard pci bridge device
Date: Tue, 21 Feb 2012 00:52:46 +0200 [thread overview]
Message-ID: <cover.1329778092.git.mst@redhat.com> (raw)
Here's a new version of the patch.
TODOs:
- windows guest testing
Changes from v2:
- added slot id capability
- migration support
- misc fixes
- fix checkpatch errors
I also include a patch to make all bridges have a user-friendly id.
You don't absolutely have to have it for testing,
but this makes use easier. Without it, you must replace
bus=<id> in instructions below with bus=<id>.0
(add ".0" literally after the id).
Changes from v1:
- hotplug support
Status: tested with a linux guest on x86.
Deep nesting of bridges is supported.
You need a small BIOS patch to support the OSHP method
if you want hotplug to work. Posted separately.
We'd need a full ACPI driver to make hotplug work for guests
without an SHPC driver (e.g. windows XP).
Management support will also be needed.
One small wrinkle is that the pci_addr property
used for pci_add command wants data in a format
bus:device.function which is
broken as guests can change bus numbers.
I don't intend to fix it short term.
So, don't use the pci_add command.
Only device_add works with a bridge.
(Side note: the 'addr' property
encodes slot*8+function#. It is not user-friendly.
Let's add optional slot= func= ?)
The SHPC controller supports up to 31 devices
(out of 32 slots) so slot 0 doesn't support hotplug.
Non hot-pluggable devices behind the bridge
don't work currectly (we'll try to unplug them)
so don't do this.
For now I just blocked adding devices in slot 0,
in the future it might be possible to add
a non-hotpluggable device there.
Each bridge must have a unique chassis #.
You *must* set it to a value > 0.
I don't check that it is unique, just that it is >0.
If you make it non unique, guest will be confused.
Example:
qemu-system-x86_64 -enable-kvm -m 1G
-drive file=/home/mst/rhel6.qcow2
-netdev
tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on
-device pci-bridge,id=bog,chassis_nr=1
-device virtio-net-pci,netdev=foo,bus=bog,addr=8
Hot-unplug currently causes qemu to crash, this
happens without this patch too, so I'm not worried :)
Michael S. Tsirkin (4):
pci_bridge: user-friendly default bus name
shpc: standard hot plug controller
slotid: add slot id capability
pci: add standard bridge device
Makefile.objs | 4 +-
hw/pci.h | 8 +
hw/pci_bridge.c | 10 +
hw/pci_bridge_dev.c | 151 ++++++++++++
hw/shpc.c | 673 +++++++++++++++++++++++++++++++++++++++++++++++++++
hw/shpc.h | 45 ++++
hw/slotid_cap.c | 44 ++++
hw/slotid_cap.h | 11 +
qemu-common.h | 1 +
9 files changed, 946 insertions(+), 1 deletions(-)
create mode 100644 hw/pci_bridge_dev.c
create mode 100644 hw/shpc.c
create mode 100644 hw/shpc.h
create mode 100644 hw/slotid_cap.c
create mode 100644 hw/slotid_cap.h
--
1.7.9.111.gf3fb0
next reply other threads:[~2012-02-20 22:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 22:52 Michael S. Tsirkin [this message]
2012-02-20 22:52 ` [Qemu-devel] [PATCHv3 0/4] standard pci bridge device Michael S. Tsirkin
2012-02-20 22:52 ` [PATCHv3 1/4] pci_bridge: user-friendly default bus name Michael S. Tsirkin
2012-02-20 22:52 ` [Qemu-devel] " Michael S. Tsirkin
2012-02-22 18:59 ` Anthony Liguori
2012-02-22 18:59 ` [Qemu-devel] " Anthony Liguori
2012-02-20 22:53 ` [PATCHv3 2/4] shpc: standard hot plug controller Michael S. Tsirkin
2012-02-20 22:53 ` [Qemu-devel] " Michael S. Tsirkin
2012-02-20 22:53 ` [PATCHv3 3/4] slotid: add slot id capability Michael S. Tsirkin
2012-02-20 22:53 ` [Qemu-devel] " Michael S. Tsirkin
2012-02-20 22:53 ` [PATCHv3 4/4] pci: add standard bridge device Michael S. Tsirkin
2012-02-20 22:53 ` [Qemu-devel] " Michael S. Tsirkin
2012-02-27 14:38 ` [PATCHv3 0/4] standard pci " Gerd Hoffmann
2012-02-27 14:38 ` [Qemu-devel] " Gerd Hoffmann
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=cover.1329778092.git.mst@redhat.com \
--to=mst@redhat.com \
--cc=avi@redhat.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yamahata@valinux.co.jp \
/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.