Re: [Qemu-devel] [PATCHv2-RFC 2/2] pci: add standard bridge device
Hi, This seems to not support 64bit prefetchable memory windows, at least linux doesn't think it does, lspci looks like this: 00:10.0 PCI bridge: Red Hat, Inc. Device 0001 (prog-if 00 [Normal decode]) [ ... ] Memory behind bridge: f600-f60f Prefetchable memory behind bridge: f800-fbff What in the above tells you that 64 bit windows are not supported? lspci prints 64bit addresses then, like this: 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) [ ... ] I/O behind bridge: 8000-8fff Memory behind bridge: c000-c01f Prefetchable memory behind bridge: c020-c03f BAR0 is 32 bit non prefetcheable. As far as I can see linux driver takes no precautions against access combining that can happen with prefetcheable BARs, so non-prefetcheable seems safer. I'm not talking about bar #0, but about the prefetchable memory window for devices behind the bridge. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2-RFC 2/2] pci: add standard bridge device
On Fri, Feb 17, 2012 at 02:33:42PM +0100, Gerd Hoffmann wrote: On 02/13/12 10:16, Michael S. Tsirkin wrote: This adds support for a standard pci to pci bridge, enabling support for more than 32 PCI devices in the system. Device hotplug is supported by means of SHPC controller. For guests with an SHPC driver, this allows robust hotplug and even hotplug of nested bridges, up to 31 devices per bridge. This seems to not support 64bit prefetchable memory windows, at least linux doesn't think it does, lspci looks like this: 00:10.0 PCI bridge: Red Hat, Inc. Device 0001 (prog-if 00 [Normal decode]) Physical Slot: 16 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Region 0: Memory at f6126000 (32-bit, non-prefetchable) [size=256] Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: f600-f60f Prefetchable memory behind bridge: f800-fbff Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [40] Hot-plug capable Kernel modules: shpchp Intentional? cheers, Gerd I'll need to check. v3 I am sending out has this code unchanged. What in the above tells you that 64 bit windows are not supported? BAR0 is 32 bit non prefetcheable. As far as I can see linux driver takes no precautions against access combining that can happen with prefetcheable BARs, so non-prefetcheable seems safer. I could make it 64 bit I guess, I just heard that there is some known bug being worked around in memory region code triggered somehow by 64 bit, and waiting for the dust to settle. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2-RFC 2/2] pci: add standard bridge device
On Fri, Feb 17, 2012 at 02:25:56PM +0100, Gerd Hoffmann wrote:
Hi,
+/* If we don't specify the name, the bus will be addressed as id.0,
where
+ * id is the parent id. But it seems more natural to address the bus
using
+ * the parent device name. */
+if (dev-qdev.id *dev-qdev.id) {
+br-bus_name = dev-qdev.id;
+}
That makes the bridge behave different than everybody else.
Not a good idea IMHO.
cheers,
Gerd
Everybody else has names built up according to an undocumented scheme
which no one can figure out without reading code, so no one uses them.
We need to fix that, but there is, generally, no need for these names
so it stayed low priority.
With the bridge people must use the id to connect devices to it,
so name must be a sane one.
--
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2-RFC 2/2] pci: add standard bridge device
On Sun, Feb 19, 2012 at 04:57:07PM +0200, Michael S. Tsirkin wrote:
On Fri, Feb 17, 2012 at 02:25:56PM +0100, Gerd Hoffmann wrote:
Hi,
+/* If we don't specify the name, the bus will be addressed as
id.0, where
+ * id is the parent id. But it seems more natural to address the
bus using
+ * the parent device name. */
+if (dev-qdev.id *dev-qdev.id) {
+br-bus_name = dev-qdev.id;
+}
That makes the bridge behave different than everybody else.
Not a good idea IMHO.
cheers,
Gerd
Everybody else has names built up according to an undocumented scheme
which no one can figure out without reading code, so no one uses them.
We need to fix that, but there is, generally, no need for these names
so it stayed low priority.
With the bridge people must use the id to connect devices to it,
so name must be a sane one.
I just sent the patch making bus id for bridges
follow the value set by the user.
That will make the bridge behave in the same way
as everybody else :)
--
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2-RFC 2/2] pci: add standard bridge device
Hi,
+/* If we don't specify the name, the bus will be addressed as id.0,
where
+ * id is the parent id. But it seems more natural to address the bus
using
+ * the parent device name. */
+if (dev-qdev.id *dev-qdev.id) {
+br-bus_name = dev-qdev.id;
+}
That makes the bridge behave different than everybody else.
Not a good idea IMHO.
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2-RFC 2/2] pci: add standard bridge device
On 02/13/12 10:16, Michael S. Tsirkin wrote: This adds support for a standard pci to pci bridge, enabling support for more than 32 PCI devices in the system. Device hotplug is supported by means of SHPC controller. For guests with an SHPC driver, this allows robust hotplug and even hotplug of nested bridges, up to 31 devices per bridge. This seems to not support 64bit prefetchable memory windows, at least linux doesn't think it does, lspci looks like this: 00:10.0 PCI bridge: Red Hat, Inc. Device 0001 (prog-if 00 [Normal decode]) Physical Slot: 16 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Region 0: Memory at f6126000 (32-bit, non-prefetchable) [size=256] Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: f600-f60f Prefetchable memory behind bridge: f800-fbff Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [40] Hot-plug capable Kernel modules: shpchp Intentional? cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
