qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv2-RFC 2/2] pci: add standard bridge device


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCHv2-RFC 2/2] pci: add standard bridge device
Date: Tue, 21 Feb 2012 00:40:02 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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: f6000000-f60fffff
>         Prefetchable memory behind bridge: f8000000-fbffffff
>         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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]