* [Qemu-devel] q35 chipset support
@ 2012-06-14 19:54 Jason Baron
2012-06-14 20:16 ` Anthony Liguori
0 siblings, 1 reply; 22+ messages in thread
From: Jason Baron @ 2012-06-14 19:54 UTC (permalink / raw)
To: qemu-devel, yamahata, anthony; +Cc: jan.kiszka, alex.williamson, mst
Hi,
I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
seabios trees. On the qemu side, most of the changes revolved around updating
to use QOM and updates to the memory API. I was also able to drop quite a few
patches that had already been resolved by the current qemu tree.
The trees seem pretty stable and can be found here:
git://github.com/jibaron/q35-qemu.git
git://github.com/jibaron/q35-seabios.git
A basic qemu cmd to start q35, looks like:
$ /usr/local/bin/qemu-system-x86_64 -name "f16" -M pc_q35 -m 1G -smp 4 -hda
./f16.img --enable-kvm -bios <path>/q35-seabios/out/bios.bin
-acpitable file=<path>/q35-seabios/out/q35-acpi-dsdt.aml -monitor stdio
The main reason to bring in q35 chipset support is for pcie support - thus
allowing drivers to make use of the extended config space, aer, pcie hotplug.
So, I wanted to start a discussion around what is missing from this patchset,
and how I should structure this patchset (perhaps, I should post the patches
to the list?). For example, does the q35 chipset support need to have feature
parity with the current i440fx before it would be considered? Or, can we bring
these features in incrementally?
As far as what I know is currently missing:
-device hotplug support needs to be added. As Michael Tsirkin pointed out
devices behind pcie bridges use up 4K i/o space, so we might quickly run out
of i/o space vs. pci bridges...
-migration vmstate needs to be updated (I didn't test or fixup migration yet)
I'm sure there is a lot more...
Thanks,
-Jason
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-14 19:54 [Qemu-devel] q35 chipset support Jason Baron
@ 2012-06-14 20:16 ` Anthony Liguori
2012-06-15 7:04 ` Markus Armbruster
2012-06-15 17:57 ` Jason Baron
0 siblings, 2 replies; 22+ messages in thread
From: Anthony Liguori @ 2012-06-14 20:16 UTC (permalink / raw)
To: Jason Baron; +Cc: yamahata, alex.williamson, jan.kiszka, qemu-devel, mst
On 06/14/2012 02:54 PM, Jason Baron wrote:
> Hi,
>
> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
> seabios trees. On the qemu side, most of the changes revolved around updating
> to use QOM and updates to the memory API. I was also able to drop quite a few
> patches that had already been resolved by the current qemu tree.
>
> The trees seem pretty stable and can be found here:
>
> git://github.com/jibaron/q35-qemu.git
> git://github.com/jibaron/q35-seabios.git
I'm got the beginnings of a feature page started:
http://wiki.qemu.org/Features/Q35
The approach above will not work in a QOM world unfortunately. We need to do
quite a bit of ground work before adding another chipset. The biggest task is
converting devices to not require an ISA bus since ICH9 simply doesn't have an
ISA bus.
You can hack things together to work without this, but the result is
unmaintainable spaghetti (which is pretty close to what we already have today).
Once the QOM bus support gets merged, I'm going to send out an ISA bus
refactoring which gets most of the platform devices away from ISA..
Regards,
Anthony Liguori
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-14 20:16 ` Anthony Liguori
@ 2012-06-15 7:04 ` Markus Armbruster
2012-06-15 17:58 ` Anthony Liguori
2012-06-15 17:57 ` Jason Baron
1 sibling, 1 reply; 22+ messages in thread
From: Markus Armbruster @ 2012-06-15 7:04 UTC (permalink / raw)
To: Anthony Liguori
Cc: mst, jan.kiszka, Jason Baron, qemu-devel, yamahata,
alex.williamson
Anthony Liguori <anthony@codemonkey.ws> writes:
> On 06/14/2012 02:54 PM, Jason Baron wrote:
>> Hi,
>>
>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>> seabios trees. On the qemu side, most of the changes revolved around updating
>> to use QOM and updates to the memory API. I was also able to drop quite a few
>> patches that had already been resolved by the current qemu tree.
>>
>> The trees seem pretty stable and can be found here:
>>
>> git://github.com/jibaron/q35-qemu.git
>> git://github.com/jibaron/q35-seabios.git
>
> I'm got the beginnings of a feature page started:
>
> http://wiki.qemu.org/Features/Q35
>
> The approach above will not work in a QOM world unfortunately. We
> need to do quite a bit of ground work before adding another chipset.
> The biggest task is converting devices to not require an ISA bus since
> ICH9 simply doesn't have an ISA bus.
Could you explain briefly why use of a software ISA bus construct
matters for device models and/or guests?
[...]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-14 20:16 ` Anthony Liguori
2012-06-15 7:04 ` Markus Armbruster
@ 2012-06-15 17:57 ` Jason Baron
2012-06-15 17:59 ` Anthony Liguori
1 sibling, 1 reply; 22+ messages in thread
From: Jason Baron @ 2012-06-15 17:57 UTC (permalink / raw)
To: Anthony Liguori; +Cc: yamahata, alex.williamson, mst, qemu-devel, jan.kiszka
On Thu, Jun 14, 2012 at 03:16:03PM -0500, Anthony Liguori wrote:
> On 06/14/2012 02:54 PM, Jason Baron wrote:
> >Hi,
> >
> >I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
> >seabios trees. On the qemu side, most of the changes revolved around updating
> >to use QOM and updates to the memory API. I was also able to drop quite a few
> >patches that had already been resolved by the current qemu tree.
> >
> >The trees seem pretty stable and can be found here:
> >
> >git://github.com/jibaron/q35-qemu.git
> >git://github.com/jibaron/q35-seabios.git
>
> I'm got the beginnings of a feature page started:
>
> http://wiki.qemu.org/Features/Q35
>
> The approach above will not work in a QOM world unfortunately. We
> need to do quite a bit of ground work before adding another chipset.
> The biggest task is converting devices to not require an ISA bus
> since ICH9 simply doesn't have an ISA bus.
>
Right, there is no h/w isa bus, but the LPC interface chip is modeled as an isa
bridge. So having an isa bus hanging off of it doesn't seem unreasonable. Unless
there is some more fundamental reason not do it this way?
It hows up in lspci as:
00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface
Controller (rev 02)
> You can hack things together to work without this, but the result is
> unmaintainable spaghetti (which is pretty close to what we already
> have today).
>
> Once the QOM bus support gets merged, I'm going to send out an ISA
> bus refactoring which gets most of the platform devices away from
> ISA..
>
> Regards,
>
> Anthony Liguori
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-15 7:04 ` Markus Armbruster
@ 2012-06-15 17:58 ` Anthony Liguori
2012-06-17 8:25 ` Michael S. Tsirkin
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Anthony Liguori @ 2012-06-15 17:58 UTC (permalink / raw)
To: Markus Armbruster
Cc: mst, jan.kiszka, Jason Baron, qemu-devel, yamahata,
alex.williamson
On 06/15/2012 02:04 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws> writes:
>
>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>> Hi,
>>>
>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>>> seabios trees. On the qemu side, most of the changes revolved around updating
>>> to use QOM and updates to the memory API. I was also able to drop quite a few
>>> patches that had already been resolved by the current qemu tree.
>>>
>>> The trees seem pretty stable and can be found here:
>>>
>>> git://github.com/jibaron/q35-qemu.git
>>> git://github.com/jibaron/q35-seabios.git
>>
>> I'm got the beginnings of a feature page started:
>>
>> http://wiki.qemu.org/Features/Q35
>>
>> The approach above will not work in a QOM world unfortunately. We
>> need to do quite a bit of ground work before adding another chipset.
>> The biggest task is converting devices to not require an ISA bus since
>> ICH9 simply doesn't have an ISA bus.
>
> Could you explain briefly why use of a software ISA bus construct
> matters for device models and/or guests?
No, but I can provide a long explanation :-)
The I440FX has a very basic device topology. The PCI host is the memory
controller and there's a PCI device that happens to have the SuperI/O chip + a
PCI-ISA bridge. There's no IOMMU and interrupt routing is simple.
The Q35 is much more sophisticated. The PCI-e complex itself can present
interesting topologies and the legacy PCI bus sits within the PCI-e complex.
You can still have a PCI-ISA bridge but the SuperI/O chip is not part of it.
Rather that's off of a separate bus (the LPC) which does not logically reside
within the PCI-e complex.
And because there is an IOMMU, this topology is visible to the guest.
Granted, initial Q35 support won't come with an IOMMU, but we will need to do
this eventually. There's already non-x86 patches floating around. Normally, I
would say we should deal with this later when we need an IOMMU but part of the
reason this is so hard to fix for the PC already is the first set of Q35 patches
we merged ages ago that introduced the silliness of pc_piix.c. The first step
in cleaning this all up is essentially reverting that first set of patches.
So we need to fix our topological representation of platform devices before we
start adding more complex chipsets. Otherwise, we're going to end up in a bad
situation in the near future.
Regards,
Anthony Liguori
>
> [...]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-15 17:57 ` Jason Baron
@ 2012-06-15 17:59 ` Anthony Liguori
2012-06-18 13:52 ` Markus Armbruster
0 siblings, 1 reply; 22+ messages in thread
From: Anthony Liguori @ 2012-06-15 17:59 UTC (permalink / raw)
To: Jason Baron; +Cc: yamahata, alex.williamson, mst, qemu-devel, jan.kiszka
On 06/15/2012 12:57 PM, Jason Baron wrote:
> On Thu, Jun 14, 2012 at 03:16:03PM -0500, Anthony Liguori wrote:
>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>> Hi,
>>>
>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>>> seabios trees. On the qemu side, most of the changes revolved around updating
>>> to use QOM and updates to the memory API. I was also able to drop quite a few
>>> patches that had already been resolved by the current qemu tree.
>>>
>>> The trees seem pretty stable and can be found here:
>>>
>>> git://github.com/jibaron/q35-qemu.git
>>> git://github.com/jibaron/q35-seabios.git
>>
>> I'm got the beginnings of a feature page started:
>>
>> http://wiki.qemu.org/Features/Q35
>>
>> The approach above will not work in a QOM world unfortunately. We
>> need to do quite a bit of ground work before adding another chipset.
>> The biggest task is converting devices to not require an ISA bus
>> since ICH9 simply doesn't have an ISA bus.
>>
>
> Right, there is no h/w isa bus, but the LPC interface chip is modeled as an isa
> bridge. So having an isa bus hanging off of it doesn't seem unreasonable. Unless
> there is some more fundamental reason not do it this way?
>
> It hows up in lspci as:
>
> 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface
> Controller (rev 02)
It's not a question of ISA vs. LPC, it's which devices are actually on that bus.
See my respond to Markus's note.
Regards,
Anthony Liguori
>
>
>
>> You can hack things together to work without this, but the result is
>> unmaintainable spaghetti (which is pretty close to what we already
>> have today).
>>
>> Once the QOM bus support gets merged, I'm going to send out an ISA
>> bus refactoring which gets most of the platform devices away from
>> ISA..
>>
>> Regards,
>>
>> Anthony Liguori
>>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-15 17:58 ` Anthony Liguori
@ 2012-06-17 8:25 ` Michael S. Tsirkin
2012-06-18 14:16 ` Anthony Liguori
2012-06-18 13:51 ` Markus Armbruster
2012-06-18 14:20 ` Michael S. Tsirkin
2 siblings, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2012-06-17 8:25 UTC (permalink / raw)
To: Anthony Liguori
Cc: jan.kiszka, Jason Baron, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
> The Q35 is much more sophisticated. The PCI-e complex itself can
> present interesting topologies and the legacy PCI bus sits within
> the PCI-e complex.
Ah, so we can mix in PCI as well? Cool. How does
such a mixed topology look?
--
MST
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-15 17:58 ` Anthony Liguori
2012-06-17 8:25 ` Michael S. Tsirkin
@ 2012-06-18 13:51 ` Markus Armbruster
2012-06-18 14:05 ` Anthony Liguori
2012-06-18 14:20 ` Michael S. Tsirkin
2 siblings, 1 reply; 22+ messages in thread
From: Markus Armbruster @ 2012-06-18 13:51 UTC (permalink / raw)
To: Anthony Liguori
Cc: mst, jan.kiszka, Jason Baron, qemu-devel, yamahata,
alex.williamson
Anthony Liguori <anthony@codemonkey.ws> writes:
> On 06/15/2012 02:04 AM, Markus Armbruster wrote:
>> Anthony Liguori<anthony@codemonkey.ws> writes:
>>
>>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>>> Hi,
>>>>
>>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>>>> seabios trees. On the qemu side, most of the changes revolved around updating
>>>> to use QOM and updates to the memory API. I was also able to drop quite a few
>>>> patches that had already been resolved by the current qemu tree.
>>>>
>>>> The trees seem pretty stable and can be found here:
>>>>
>>>> git://github.com/jibaron/q35-qemu.git
>>>> git://github.com/jibaron/q35-seabios.git
>>>
>>> I'm got the beginnings of a feature page started:
>>>
>>> http://wiki.qemu.org/Features/Q35
>>>
>>> The approach above will not work in a QOM world unfortunately. We
>>> need to do quite a bit of ground work before adding another chipset.
>>> The biggest task is converting devices to not require an ISA bus since
>>> ICH9 simply doesn't have an ISA bus.
>>
>> Could you explain briefly why use of a software ISA bus construct
>> matters for device models and/or guests?
>
> No, but I can provide a long explanation :-)
Thanks!
> The I440FX has a very basic device topology. The PCI host is the
> memory controller and there's a PCI device that happens to have the
> SuperI/O chip + a PCI-ISA bridge. There's no IOMMU and interrupt
> routing is simple.
PC interrupt routing is hardly ever "simple", but I get what you mean ;)
> The Q35 is much more sophisticated. The PCI-e complex itself can
> present interesting topologies and the legacy PCI bus sits within the
> PCI-e complex. You can still have a PCI-ISA bridge but the SuperI/O
> chip is not part of it. Rather that's off of a separate bus (the LPC)
> which does not logically reside within the PCI-e complex.
Let's whether I understand.
The platform devices do *not* sit behind a PCI-ISA bridge (in fact, no
such bridge exists normally). Instead, they're connected via LPC.
What I don't get is why that connection can't be modelled as an ISA bus.
Provided by a Systembus-ISA bridge if you like.
> And because there is an IOMMU, this topology is visible to the guest.
>
> Granted, initial Q35 support won't come with an IOMMU, but we will
> need to do this eventually. There's already non-x86 patches floating
> around. Normally, I would say we should deal with this later when we
> need an IOMMU but part of the reason this is so hard to fix for the PC
> already is the first set of Q35 patches we merged ages ago that
> introduced the silliness of pc_piix.c. The first step in cleaning
> this all up is essentially reverting that first set of patches.
>
> So we need to fix our topological representation of platform devices
> before we start adding more complex chipsets. Otherwise, we're going
> to end up in a bad situation in the near future.
I'm not sufficiently familiar with the first set of Q35 patches to risk
an opinion here...
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-15 17:59 ` Anthony Liguori
@ 2012-06-18 13:52 ` Markus Armbruster
2012-06-18 14:38 ` Michael S. Tsirkin
0 siblings, 1 reply; 22+ messages in thread
From: Markus Armbruster @ 2012-06-18 13:52 UTC (permalink / raw)
To: Anthony Liguori
Cc: mst, jan.kiszka, Jason Baron, qemu-devel, yamahata,
alex.williamson
Anthony Liguori <anthony@codemonkey.ws> writes:
> On 06/15/2012 12:57 PM, Jason Baron wrote:
>> On Thu, Jun 14, 2012 at 03:16:03PM -0500, Anthony Liguori wrote:
>>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>>> Hi,
>>>>
>>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>>>> seabios trees. On the qemu side, most of the changes revolved around updating
>>>> to use QOM and updates to the memory API. I was also able to drop quite a few
>>>> patches that had already been resolved by the current qemu tree.
>>>>
>>>> The trees seem pretty stable and can be found here:
>>>>
>>>> git://github.com/jibaron/q35-qemu.git
>>>> git://github.com/jibaron/q35-seabios.git
>>>
>>> I'm got the beginnings of a feature page started:
>>>
>>> http://wiki.qemu.org/Features/Q35
>>>
>>> The approach above will not work in a QOM world unfortunately. We
>>> need to do quite a bit of ground work before adding another chipset.
>>> The biggest task is converting devices to not require an ISA bus
>>> since ICH9 simply doesn't have an ISA bus.
>>>
>>
>> Right, there is no h/w isa bus, but the LPC interface chip is modeled as an isa
>> bridge. So having an isa bus hanging off of it doesn't seem unreasonable. Unless
>> there is some more fundamental reason not do it this way?
>>
>> It hows up in lspci as:
>>
>> 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface
>> Controller (rev 02)
>
> It's not a question of ISA vs. LPC, it's which devices are actually on
> that bus. See my respond to Markus's note.
Maybe I'm naive, but platform devices handing off an ISA bus provided by
that ICH9 ISA bridge looks like a fair approximation to me. Yes, the
actual wiring is LPC, but that's a hardware detail invisible to device
models and guest, isn't it?
Of course, you can't connect anything but the platform devices to that
bus. To connect other ISA devices, you'd have to add a second ISA
bridge. I suspect that's what you meant by "You can still have a
PCI-ISA bridge but the SuperI/O chip is not part of it" elsewhere in
this thread.
No idea whether such beasts exist in the physical world, and how they
work.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 13:51 ` Markus Armbruster
@ 2012-06-18 14:05 ` Anthony Liguori
2012-06-18 20:36 ` Jason Baron
0 siblings, 1 reply; 22+ messages in thread
From: Anthony Liguori @ 2012-06-18 14:05 UTC (permalink / raw)
To: Markus Armbruster
Cc: mst, jan.kiszka, Jason Baron, qemu-devel, yamahata,
alex.williamson
On 06/18/2012 08:51 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws> writes:
>
>> On 06/15/2012 02:04 AM, Markus Armbruster wrote:
>>> Anthony Liguori<anthony@codemonkey.ws> writes:
>>>
>>>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>>>> Hi,
>>>>>
>>>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>>>>> seabios trees. On the qemu side, most of the changes revolved around updating
>>>>> to use QOM and updates to the memory API. I was also able to drop quite a few
>>>>> patches that had already been resolved by the current qemu tree.
>>>>>
>>>>> The trees seem pretty stable and can be found here:
>>>>>
>>>>> git://github.com/jibaron/q35-qemu.git
>>>>> git://github.com/jibaron/q35-seabios.git
>>>>
>>>> I'm got the beginnings of a feature page started:
>>>>
>>>> http://wiki.qemu.org/Features/Q35
>>>>
>>>> The approach above will not work in a QOM world unfortunately. We
>>>> need to do quite a bit of ground work before adding another chipset.
>>>> The biggest task is converting devices to not require an ISA bus since
>>>> ICH9 simply doesn't have an ISA bus.
>>>
>>> Could you explain briefly why use of a software ISA bus construct
>>> matters for device models and/or guests?
>>
>> No, but I can provide a long explanation :-)
>
> Thanks!
>
>> The I440FX has a very basic device topology. The PCI host is the
>> memory controller and there's a PCI device that happens to have the
>> SuperI/O chip + a PCI-ISA bridge. There's no IOMMU and interrupt
>> routing is simple.
>
> PC interrupt routing is hardly ever "simple", but I get what you mean ;)
>
>> The Q35 is much more sophisticated. The PCI-e complex itself can
>> present interesting topologies and the legacy PCI bus sits within the
>> PCI-e complex. You can still have a PCI-ISA bridge but the SuperI/O
>> chip is not part of it. Rather that's off of a separate bus (the LPC)
>> which does not logically reside within the PCI-e complex.
>
> Let's whether I understand.
>
> The platform devices do *not* sit behind a PCI-ISA bridge (in fact, no
> such bridge exists normally). Instead, they're connected via LPC.
No, *some* platform devices are connected via LPC. Some are not.
To give you an example: both LPC and ISA provide a bus-level DMA interface.
When you think of IOMMU modeling, it looks something like this:
Floppy controller:
isa_memory_read(isa_dev, ...)
-> talks to DMA controller
DMA controller:
Implemented in PIIX4 for I440FX, within ICH9 for q35
Uses cpu_physical_memory_rw() which takes the get_system() MemoryRegion
So we cannot have the DMA controller be a ISA/LPC device as we do today because
the ISA bus should only use isa_memory_read() which is implemented by the DMA
controller. We have an infinite modeling loop today :-)
> What I don't get is why that connection can't be modelled as an ISA bus.
> Provided by a Systembus-ISA bridge if you like.
To be clear, it's not LPC vs. ISA. We can't just make all platform devices an X
bus device. There's more of a hierarchy and it's guest visible once we throw in
an IOMMU capable chipset.
Regards,
Anthony Liguori
>> And because there is an IOMMU, this topology is visible to the guest.
>>
>> Granted, initial Q35 support won't come with an IOMMU, but we will
>> need to do this eventually. There's already non-x86 patches floating
>> around. Normally, I would say we should deal with this later when we
>> need an IOMMU but part of the reason this is so hard to fix for the PC
>> already is the first set of Q35 patches we merged ages ago that
>> introduced the silliness of pc_piix.c. The first step in cleaning
>> this all up is essentially reverting that first set of patches.
>>
>> So we need to fix our topological representation of platform devices
>> before we start adding more complex chipsets. Otherwise, we're going
>> to end up in a bad situation in the near future.
>
> I'm not sufficiently familiar with the first set of Q35 patches to risk
> an opinion here...
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-17 8:25 ` Michael S. Tsirkin
@ 2012-06-18 14:16 ` Anthony Liguori
2012-06-18 14:35 ` Michael S. Tsirkin
0 siblings, 1 reply; 22+ messages in thread
From: Anthony Liguori @ 2012-06-18 14:16 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jan.kiszka, Jason Baron, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
On 06/17/2012 03:25 AM, Michael S. Tsirkin wrote:
> On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
>> The Q35 is much more sophisticated. The PCI-e complex itself can
>> present interesting topologies and the legacy PCI bus sits within
>> the PCI-e complex.
>
> Ah, so we can mix in PCI as well? Cool. How does
> such a mixed topology look?
It does, but I'm having a really hard time deciphering the spec here. Here's
what it says:
"The ICH9 PCI interface provides a 33 MHz, Revision 2.3 implementation. The ICH9
integrates a PCI arbiter that supports up to four external PCI bus masters in
addition to the internal ICH9 requests. This allows for combinations of up to
four PCI down devices and PCI slots."
So my interpretation of this is that it provides the ability to expose legacy
PCI slots. I can't get a reading though on how this shows up in the PCI
topology though.
It sounds like it would show up as a separate PCI domain.
Regards,
Anthony Liguori
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-15 17:58 ` Anthony Liguori
2012-06-17 8:25 ` Michael S. Tsirkin
2012-06-18 13:51 ` Markus Armbruster
@ 2012-06-18 14:20 ` Michael S. Tsirkin
2012-06-18 14:22 ` Anthony Liguori
2 siblings, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2012-06-18 14:20 UTC (permalink / raw)
To: Anthony Liguori
Cc: jan.kiszka, Jason Baron, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
> So we need to fix our topological representation of platform devices
> before we start adding more complex chipsets. Otherwise, we're
> going to end up in a bad situation in the near future.
OTOH more in-tree examples especially for x86 will keep us
honest: help make sure abstractions make sense,
and prevent people from special casing piix because
this is the prevalent platform for kvm ATM.
--
MST
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 14:20 ` Michael S. Tsirkin
@ 2012-06-18 14:22 ` Anthony Liguori
2012-06-18 14:37 ` Michael S. Tsirkin
0 siblings, 1 reply; 22+ messages in thread
From: Anthony Liguori @ 2012-06-18 14:22 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jan.kiszka, Jason Baron, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
On 06/18/2012 09:20 AM, Michael S. Tsirkin wrote:
> On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
>> So we need to fix our topological representation of platform devices
>> before we start adding more complex chipsets. Otherwise, we're
>> going to end up in a bad situation in the near future.
>
> OTOH more in-tree examples especially for x86 will keep us
> honest: help make sure abstractions make sense,
> and prevent people from special casing piix because
> this is the prevalent platform for kvm ATM.
Yes, more in-tree *correct* examples. I'm very much in favor of merging q35.
Regards,
Anthony Liguori
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 14:16 ` Anthony Liguori
@ 2012-06-18 14:35 ` Michael S. Tsirkin
2012-06-18 15:15 ` Anthony Liguori
2012-06-18 16:04 ` Jason Baron
0 siblings, 2 replies; 22+ messages in thread
From: Michael S. Tsirkin @ 2012-06-18 14:35 UTC (permalink / raw)
To: Anthony Liguori
Cc: jan.kiszka, Jason Baron, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Mon, Jun 18, 2012 at 09:16:24AM -0500, Anthony Liguori wrote:
> On 06/17/2012 03:25 AM, Michael S. Tsirkin wrote:
> >On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
> >>The Q35 is much more sophisticated. The PCI-e complex itself can
> >>present interesting topologies and the legacy PCI bus sits within
> >>the PCI-e complex.
> >
> >Ah, so we can mix in PCI as well? Cool. How does
> >such a mixed topology look?
>
> It does, but I'm having a really hard time deciphering the spec
> here. Here's what it says:
>
> "The ICH9 PCI interface provides a 33 MHz, Revision 2.3 implementation. The ICH9
> integrates a PCI arbiter that supports up to four external PCI bus
> masters in addition to the internal ICH9 requests. This allows for
> combinations of up to four PCI down devices and PCI slots."
>
> So my interpretation of this is that it provides the ability to
> expose legacy PCI slots. I can't get a reading though on how this
> shows up in the PCI topology though.
>
> It sounds like it would show up as a separate PCI domain.
>
> Regards,
>
> Anthony Liguori
Actually I found a box with ICH9
http://fpaste.org/VREA/
or see attached.
It looks like there's at least one PCI bridge attached to
the host bridge.
> >
[-- Attachment #2: tuck-lspci.txt --]
[-- Type: text/plain, Size: 42022 bytes --]
[mst@tuck ~]$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
00:03.3 Serial controller: Intel Corporation Mobile 4 Series Chipset AMT SOL Redirection (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
15:00.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11)
15:00.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 11)
[mst@tuck ~]$ sudo lspci -vv
[sudo] password for mst:
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
Subsystem: Lenovo Device 20e0
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
Capabilities: [e0] Vendor Specific Information: Len=0a <?>
Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 20e4
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
Interrupt: pin A routed to IRQ 45
Region 0: Memory at f4400000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 1800 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 41a1
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
Kernel modules: i915
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
Subsystem: Lenovo Device 20e4
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 f4200000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
Subsystem: Lenovo Device 20e6
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
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fc226800 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
00:03.3 Serial controller: Intel Corporation Mobile 4 Series Chipset AMT SOL Redirection (rev 07) (prog-if 02 [16550])
Subsystem: Lenovo Device 20ec
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
Interrupt: pin B routed to IRQ 17
Region 0: I/O ports at 1830 [size=8]
Region 1: Memory at fc024000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Kernel driver in use: serial
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
Subsystem: Lenovo Device 20ee
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
Interrupt: pin A routed to IRQ 46
Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at fc025000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 1840 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 416c
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 20
Region 4: I/O ports at 1860 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports at 1880 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 22
Region 4: I/O ports at 18a0 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) (prog-if 20 [EHCI])
Subsystem: Lenovo Device 20f1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 23
Region 0: Memory at fc226c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci_hcd
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
Subsystem: Lenovo Device 20f2
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, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 47
Region 0: Memory at fc020000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 415c
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: snd_hda_intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode])
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, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00009000-00009fff
Memory behind bridge: c0200000-c03fffff
Prefetchable memory behind bridge: 00000000c0400000-00000000c05fffff
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] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #0, PowerLimit 6.500W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c Data: 4179
Capabilities: [90] Subsystem: Lenovo Device 20f3
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=01 ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) (prog-if 00 [Normal decode])
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, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00008000-00008fff
Memory behind bridge: f4300000-f43fffff
Prefetchable memory behind bridge: 00000000c0000000-00000000c01fffff
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] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #1, PowerLimit 6.500W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c Data: 4181
Capabilities: [90] Subsystem: Lenovo Device 20f3
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=02 ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) (prog-if 00 [Normal decode])
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, Cache Line Size: 64 bytes
Bus: primary=00, secondary=05, subordinate=0c, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: f8000000-f9ffffff
Prefetchable memory behind bridge: 00000000f4000000-00000000f40fffff
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] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #3, PowerLimit 6.500W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c Data: 4189
Capabilities: [90] Subsystem: Lenovo Device 20f3
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=04 ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) (prog-if 00 [Normal decode])
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, Cache Line Size: 64 bytes
Bus: primary=00, secondary=0d, subordinate=14, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: fa000000-fbffffff
Prefetchable memory behind bridge: 00000000f4100000-00000000f41fffff
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] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #5, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #4, PowerLimit 6.500W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c Data: 4191
Capabilities: [90] Subsystem: Lenovo Device 20f3
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=05 ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 4: I/O ports at 18c0 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 17
Region 4: I/O ports at 18e0 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at 1c00 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
Subsystem: Lenovo Device 20f1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 19
Region 0: Memory at fc227000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) (prog-if 01 [Subtractive decode])
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
Bus: primary=00, secondary=15, subordinate=18, sec-latency=32
I/O behind bridge: 00004000-00007fff
Memory behind bridge: f4800000-f7ffffff
Prefetchable memory behind bridge: 00000000f0000000-00000000f3ffffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Subsystem: Lenovo Device 20f4
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
Subsystem: Lenovo Device 20f5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel modules: iTCO_wdt
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo Device 20f8
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 44
Region 0: I/O ports at 1c48 [size=8]
Region 1: I/O ports at 183c [size=4]
Region 2: I/O ports at 1c40 [size=8]
Region 3: I/O ports at 1838 [size=4]
Region 4: I/O ports at 1c20 [size=32]
Region 5: Memory at fc226000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/16 Maskable- 64bit-
Address: fee0300c Data: 4199
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
Subsystem: Lenovo Device 20f9
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 23
Region 0: Memory at fc227400 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 1c60 [size=32]
Kernel driver in use: i801_smbus
Kernel modules: i2c-i801
03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
Subsystem: Intel Corporation WiFi Link 5100 AGN
Physical Slot: 1
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, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 48
Region 0: Memory at f4300000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0100c Data: 41b9
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <32us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-22-fa-ff-ff-94-43-ea
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
Subsystem: Lenovo Device 20c6
Physical Slot: 1-1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 168, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f4800000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=15, secondary=16, subordinate=17, sec-latency=176
Memory window 0: f0000000-f3fff000 (prefetchable)
Memory window 1: c4000000-c7fff000
I/O window 0: 00004400-000044ff
I/O window 1: 00004000-000040ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
Kernel driver in use: yenta_cardbus
Kernel modules: yenta_socket
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04) (prog-if 10 [OHCI])
Subsystem: Lenovo Device 20c7
Physical Slot: 1-1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (500ns min, 1000ns max), Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at f4801000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME+
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
Subsystem: Lenovo Device 20c8
Physical Slot: 1-1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin C routed to IRQ 18
Region 0: Memory at f4801800 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: sdhci-pci
Kernel modules: sdhci-pci
15:00.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11)
Subsystem: Lenovo ThinkPad T61
Physical Slot: 1-1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin C routed to IRQ 18
Region 0: Memory at f4802000 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: r592
Kernel modules: r592
15:00.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 11)
Subsystem: Lenovo Device 20cb
Physical Slot: 1-1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin C routed to IRQ 18
Region 0: Memory at f4802400 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: r852
Kernel modules: r852
[mst@tuck ~]$
[mst@tuck ~]$ sudo lspci -t
-[0000:00]-+-00.0
+-02.0
+-02.1
+-03.0
+-03.3
+-19.0
+-1a.0
+-1a.1
+-1a.2
+-1a.7
+-1b.0
+-1c.0-[02]--
+-1c.1-[03]----00.0
+-1c.3-[05-0c]--
+-1c.4-[0d-14]--
+-1d.0
+-1d.1
+-1d.2
+-1d.7
+-1e.0-[15-18]--+-00.0
| +-00.1
| +-00.2
| +-00.4
| \-00.5
+-1f.0
+-1f.2
\-1f.3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 14:22 ` Anthony Liguori
@ 2012-06-18 14:37 ` Michael S. Tsirkin
2012-06-18 15:36 ` Andreas Färber
0 siblings, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2012-06-18 14:37 UTC (permalink / raw)
To: Anthony Liguori
Cc: jan.kiszka, Jason Baron, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
On Mon, Jun 18, 2012 at 09:22:43AM -0500, Anthony Liguori wrote:
> On 06/18/2012 09:20 AM, Michael S. Tsirkin wrote:
> >On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
> >>So we need to fix our topological representation of platform devices
> >>before we start adding more complex chipsets. Otherwise, we're
> >>going to end up in a bad situation in the near future.
> >
> >OTOH more in-tree examples especially for x86 will keep us
> >honest: help make sure abstractions make sense,
> >and prevent people from special casing piix because
> >this is the prevalent platform for kvm ATM.
>
> Yes, more in-tree *correct* examples. I'm very much in favor of merging q35.
>
> Regards,
>
> Anthony Liguori
But is there a way to build a correct chipset right now?
Or is this blocked waiting for more infrastructure
to get merged?
--
MST
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 13:52 ` Markus Armbruster
@ 2012-06-18 14:38 ` Michael S. Tsirkin
0 siblings, 0 replies; 22+ messages in thread
From: Michael S. Tsirkin @ 2012-06-18 14:38 UTC (permalink / raw)
To: Markus Armbruster
Cc: jan.kiszka, Jason Baron, qemu-devel, yamahata, alex.williamson,
Anthony Liguori
On Mon, Jun 18, 2012 at 03:52:34PM +0200, Markus Armbruster wrote:
> Anthony Liguori <anthony@codemonkey.ws> writes:
>
> > On 06/15/2012 12:57 PM, Jason Baron wrote:
> >> On Thu, Jun 14, 2012 at 03:16:03PM -0500, Anthony Liguori wrote:
> >>> On 06/14/2012 02:54 PM, Jason Baron wrote:
> >>>> Hi,
> >>>>
> >>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
> >>>> seabios trees. On the qemu side, most of the changes revolved around updating
> >>>> to use QOM and updates to the memory API. I was also able to drop quite a few
> >>>> patches that had already been resolved by the current qemu tree.
> >>>>
> >>>> The trees seem pretty stable and can be found here:
> >>>>
> >>>> git://github.com/jibaron/q35-qemu.git
> >>>> git://github.com/jibaron/q35-seabios.git
> >>>
> >>> I'm got the beginnings of a feature page started:
> >>>
> >>> http://wiki.qemu.org/Features/Q35
> >>>
> >>> The approach above will not work in a QOM world unfortunately. We
> >>> need to do quite a bit of ground work before adding another chipset.
> >>> The biggest task is converting devices to not require an ISA bus
> >>> since ICH9 simply doesn't have an ISA bus.
> >>>
> >>
> >> Right, there is no h/w isa bus, but the LPC interface chip is modeled as an isa
> >> bridge. So having an isa bus hanging off of it doesn't seem unreasonable. Unless
> >> there is some more fundamental reason not do it this way?
> >>
> >> It hows up in lspci as:
> >>
> >> 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface
> >> Controller (rev 02)
> >
> > It's not a question of ISA vs. LPC, it's which devices are actually on
> > that bus. See my respond to Markus's note.
>
> Maybe I'm naive, but platform devices handing off an ISA bus provided by
> that ICH9 ISA bridge looks like a fair approximation to me. Yes, the
> actual wiring is LPC, but that's a hardware detail invisible to device
> models and guest, isn't it?
>
> Of course, you can't connect anything but the platform devices to that
> bus. To connect other ISA devices, you'd have to add a second ISA
> bridge. I suspect that's what you meant by "You can still have a
> PCI-ISA bridge but the SuperI/O chip is not part of it" elsewhere in
> this thread.
>
> No idea whether such beasts exist in the physical world, and how they
> work.
See a dump from an old machine of mine (thinkpad T500 FWIW):
it does have an ISA bridge behind the root bus.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 14:35 ` Michael S. Tsirkin
@ 2012-06-18 15:15 ` Anthony Liguori
2012-06-18 16:04 ` Jason Baron
1 sibling, 0 replies; 22+ messages in thread
From: Anthony Liguori @ 2012-06-18 15:15 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jan.kiszka, Jason Baron, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
On 06/18/2012 09:35 AM, Michael S. Tsirkin wrote:
> On Mon, Jun 18, 2012 at 09:16:24AM -0500, Anthony Liguori wrote:
>> On 06/17/2012 03:25 AM, Michael S. Tsirkin wrote:
>>> On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
>>>> The Q35 is much more sophisticated. The PCI-e complex itself can
>>>> present interesting topologies and the legacy PCI bus sits within
>>>> the PCI-e complex.
>>>
>>> Ah, so we can mix in PCI as well? Cool. How does
>>> such a mixed topology look?
>>
>> It does, but I'm having a really hard time deciphering the spec
>> here. Here's what it says:
>>
>> "The ICH9 PCI interface provides a 33 MHz, Revision 2.3 implementation. The ICH9
>> integrates a PCI arbiter that supports up to four external PCI bus
>> masters in addition to the internal ICH9 requests. This allows for
>> combinations of up to four PCI down devices and PCI slots."
>>
>> So my interpretation of this is that it provides the ability to
>> expose legacy PCI slots. I can't get a reading though on how this
>> shows up in the PCI topology though.
>>
>> It sounds like it would show up as a separate PCI domain.
>>
>> Regards,
>>
>> Anthony Liguori
>
> Actually I found a box with ICH9
> http://fpaste.org/VREA/
> or see attached.
>
> It looks like there's at least one PCI bridge attached to
> the host bridge.
Right, and it appears to be a 2.3 bridge (the express capability isn't set).
I guess that's the mobile PCI expansion slots as it has a flash card reader in it.
Regards,
Anthony Liguori
>
>>>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 14:37 ` Michael S. Tsirkin
@ 2012-06-18 15:36 ` Andreas Färber
2012-06-18 15:45 ` Anthony Liguori
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Färber @ 2012-06-18 15:36 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jan.kiszka, Jason Baron, qemu-devel, Markus Armbruster, yamahata,
alex.williamson, Anthony Liguori
Am 18.06.2012 16:37, schrieb Michael S. Tsirkin:
> On Mon, Jun 18, 2012 at 09:22:43AM -0500, Anthony Liguori wrote:
>> On 06/18/2012 09:20 AM, Michael S. Tsirkin wrote:
>>> On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
>>>> So we need to fix our topological representation of platform devices
>>>> before we start adding more complex chipsets. Otherwise, we're
>>>> going to end up in a bad situation in the near future.
>>>
>>> OTOH more in-tree examples especially for x86 will keep us
>>> honest: help make sure abstractions make sense,
>>> and prevent people from special casing piix because
>>> this is the prevalent platform for kvm ATM.
>>
>> Yes, more in-tree *correct* examples. I'm very much in favor of merging q35.
>
> But is there a way to build a correct chipset right now?
> Or is this blocked waiting for more infrastructure
> to get merged?
The qom-next PULL (with QBus type) is out and Anthony has reviewed my
pci_host mini-series, those two would be good to have as groundwork.
Anything else (e.g., an LPCBus if needed) could be done in the q35
series IIUC.
Having q35 modeled with in-place initialization should probably not be a
hard requirement, relaxing the PCIBus availability issue.
>From what I remember from attempting to refactor the DEC bridge though,
the PCI functions hardcode the domain to 1 currently?
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 15:36 ` Andreas Färber
@ 2012-06-18 15:45 ` Anthony Liguori
0 siblings, 0 replies; 22+ messages in thread
From: Anthony Liguori @ 2012-06-18 15:45 UTC (permalink / raw)
To: Andreas Färber
Cc: Michael S. Tsirkin, jan.kiszka, Jason Baron, qemu-devel,
Markus Armbruster, yamahata, alex.williamson
On 06/18/2012 10:36 AM, Andreas Färber wrote:
> Am 18.06.2012 16:37, schrieb Michael S. Tsirkin:
>> On Mon, Jun 18, 2012 at 09:22:43AM -0500, Anthony Liguori wrote:
>>> On 06/18/2012 09:20 AM, Michael S. Tsirkin wrote:
>>>> On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
>>>>> So we need to fix our topological representation of platform devices
>>>>> before we start adding more complex chipsets. Otherwise, we're
>>>>> going to end up in a bad situation in the near future.
>>>>
>>>> OTOH more in-tree examples especially for x86 will keep us
>>>> honest: help make sure abstractions make sense,
>>>> and prevent people from special casing piix because
>>>> this is the prevalent platform for kvm ATM.
>>>
>>> Yes, more in-tree *correct* examples. I'm very much in favor of merging q35.
>>
>> But is there a way to build a correct chipset right now?
>> Or is this blocked waiting for more infrastructure
>> to get merged?
>
> The qom-next PULL (with QBus type) is out and Anthony has reviewed my
> pci_host mini-series, those two would be good to have as groundwork.
> Anything else (e.g., an LPCBus if needed) could be done in the q35
> series IIUC.
>
> Having q35 modeled with in-place initialization should probably not be a
> hard requirement, relaxing the PCIBus availability issue.
All I think is required is that we have the right hiearchy of devices. I don't
mind if we're not doing two-stage initialization but we need to make sure the
device hierarchy represents what the guest expects to see.
Regards,
Anthony Liguori
>
> From what I remember from attempting to refactor the DEC bridge though,
> the PCI functions hardcode the domain to 1 currently?
>
> Andreas
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 14:35 ` Michael S. Tsirkin
2012-06-18 15:15 ` Anthony Liguori
@ 2012-06-18 16:04 ` Jason Baron
1 sibling, 0 replies; 22+ messages in thread
From: Jason Baron @ 2012-06-18 16:04 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jan.kiszka, qemu-devel, Markus Armbruster, yamahata,
alex.williamson, Anthony Liguori
On Mon, Jun 18, 2012 at 05:35:02PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 18, 2012 at 09:16:24AM -0500, Anthony Liguori wrote:
> > On 06/17/2012 03:25 AM, Michael S. Tsirkin wrote:
> > >On Fri, Jun 15, 2012 at 12:58:33PM -0500, Anthony Liguori wrote:
> > >>The Q35 is much more sophisticated. The PCI-e complex itself can
> > >>present interesting topologies and the legacy PCI bus sits within
> > >>the PCI-e complex.
> > >
> > >Ah, so we can mix in PCI as well? Cool. How does
> > >such a mixed topology look?
> >
> > It does, but I'm having a really hard time deciphering the spec
> > here. Here's what it says:
> >
> > "The ICH9 PCI interface provides a 33 MHz, Revision 2.3 implementation. The ICH9
> > integrates a PCI arbiter that supports up to four external PCI bus
> > masters in addition to the internal ICH9 requests. This allows for
> > combinations of up to four PCI down devices and PCI slots."
> >
> > So my interpretation of this is that it provides the ability to
> > expose legacy PCI slots. I can't get a reading though on how this
> > shows up in the PCI topology though.
> >
> > It sounds like it would show up as a separate PCI domain.
> >
> > Regards,
> >
> > Anthony Liguori
>
> Actually I found a box with ICH9
> http://fpaste.org/VREA/
> or see attached.
>
> It looks like there's at least one PCI bridge attached to
> the host bridge.
>
> > >
> [mst@tuck ~]$ lspci
> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
> 00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
> 00:03.3 Serial controller: Intel Corporation Mobile 4 Series Chipset AMT SOL Redirection (rev 07)
> 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
> 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
> 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
> 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
> 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
> 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03)
> 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
> 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
> 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
> 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
> 00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
> 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
> 03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
> 15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
> 15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
> 15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
> 15:00.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11)
> 15:00.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 11)
The qemu q35 model that I have also puts the pci bridge at '1e', here is the lspci,
lspci -t output:
[jibaron@localhost ~]$ lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller
00:01.0 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
00:17.0 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:18.0 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:1c.0 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 5500 Non-Legacy I/O Hub PCI Express Root Port 0 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
03:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Upstream) (rev 02)
04:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (rev 01)
0c:1c.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05)
0c:1d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05)
0c:1e.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05)
0c:1f.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05)
[jibaron@localhost ~]$ lspci -t
-[0000:00]-+-00.0
+-01.0-[01]--
+-02.0
+-03.0
+-17.0-[02]--
+-18.0-[03-05]----00.0-[04-05]----00.0-[05]--
+-1c.0-[06]--
+-1c.1-[07]--
+-1c.2-[08]--
+-1c.3-[09]--
+-1c.4-[0a]--
+-1c.5-[0b]--
+-1e.0-[0c-10]--+-1c.0-[0d]--
| +-1d.0-[0e]--
| +-1e.0-[0f]--
| \-1f.0-[10]--
+-1f.0
+-1f.2
\-1f.3
> [mst@tuck ~]$ sudo lspci -vv
> [sudo] password for mst:
> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
> Subsystem: Lenovo Device 20e0
> 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
> Capabilities: [e0] Vendor Specific Information: Len=0a <?>
> Kernel driver in use: agpgart-intel
>
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
> Subsystem: Lenovo Device 20e4
> 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
> Interrupt: pin A routed to IRQ 45
> Region 0: Memory at f4400000 (64-bit, non-prefetchable) [size=4M]
> Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
> Region 4: I/O ports at 1800 [size=8]
> Expansion ROM at <unassigned> [disabled]
> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: fee0300c Data: 41a1
> Capabilities: [d0] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: i915
> Kernel modules: i915
>
> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
> Subsystem: Lenovo Device 20e4
> 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 f4200000 (64-bit, non-prefetchable) [size=1M]
> Capabilities: [d0] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>
> 00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
> Subsystem: Lenovo Device 20e6
> 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
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at fc226800 (64-bit, non-prefetchable) [size=16]
> Capabilities: [50] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+
> Address: 0000000000000000 Data: 0000
>
> 00:03.3 Serial controller: Intel Corporation Mobile 4 Series Chipset AMT SOL Redirection (rev 07) (prog-if 02 [16550])
> Subsystem: Lenovo Device 20ec
> 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
> Interrupt: pin B routed to IRQ 17
> Region 0: I/O ports at 1830 [size=8]
> Region 1: Memory at fc024000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [c8] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
> Address: 0000000000000000 Data: 0000
> Kernel driver in use: serial
>
> 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
> Subsystem: Lenovo Device 20ee
> 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
> Interrupt: pin A routed to IRQ 46
> Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at fc025000 (32-bit, non-prefetchable) [size=4K]
> Region 2: I/O ports at 1840 [size=32]
> Capabilities: [c8] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0300c Data: 416c
> Capabilities: [e0] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: e1000e
> Kernel modules: e1000e
>
> 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device 20f0
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 20
> Region 4: I/O ports at 1860 [size=32]
> Capabilities: [50] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: uhci_hcd
>
> 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device 20f0
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin B routed to IRQ 21
> Region 4: I/O ports at 1880 [size=32]
> Capabilities: [50] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: uhci_hcd
>
> 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device 20f0
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin C routed to IRQ 22
> Region 4: I/O ports at 18a0 [size=32]
> Capabilities: [50] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: uhci_hcd
>
> 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) (prog-if 20 [EHCI])
> Subsystem: Lenovo Device 20f1
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin D routed to IRQ 23
> Region 0: Memory at fc226c00 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
> Capabilities: [58] Debug port: BAR=1 offset=00a0
> Capabilities: [98] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: ehci_hcd
>
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
> Subsystem: Lenovo Device 20f2
> 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, Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 47
> Region 0: Memory at fc020000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0300c Data: 415c
> Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
> ExtTag- RBE- FLReset+
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
> Capabilities: [100 v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed- WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
> Status: NegoPending- InProgress-
> VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00
> Status: NegoPending- InProgress-
> Capabilities: [130 v1] Root Complex Link
> Desc: PortNumber=0f ComponentID=02 EltType=Config
> Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
> Addr: 00000000fed1c000
> Kernel driver in use: snd_hda_intel
> Kernel modules: snd-hda-intel
>
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode])
> 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, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
> I/O behind bridge: 00009000-00009fff
> Memory behind bridge: c0200000-c03fffff
> Prefetchable memory behind bridge: 00000000c0400000-00000000c05fffff
> 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] Express (v1) Root Port (Slot+), MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
> ExtTag- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <4us
> ClockPM- Surprise- LLActRep+ BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
> Slot #0, PowerLimit 6.500W; Interlock- NoCompl-
> SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
> Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
> SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
> Changed: MRL- PresDet- LinkState-
> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
> RootCap: CRSVisible-
> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: fee0100c Data: 4179
> Capabilities: [90] Subsystem: Lenovo Device 20f3
> Capabilities: [a0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [100 v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed+ WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
> Status: NegoPending- InProgress-
> Capabilities: [180 v1] Root Complex Link
> Desc: PortNumber=01 ComponentID=02 EltType=Config
> Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
> Addr: 00000000fed1c000
> Kernel driver in use: pcieport
>
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) (prog-if 00 [Normal decode])
> 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, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
> I/O behind bridge: 00008000-00008fff
> Memory behind bridge: f4300000-f43fffff
> Prefetchable memory behind bridge: 00000000c0000000-00000000c01fffff
> 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] Express (v1) Root Port (Slot+), MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
> ExtTag- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> LnkCap: Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
> ClockPM- Surprise- LLActRep+ BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
> Slot #1, PowerLimit 6.500W; Interlock- NoCompl-
> SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
> Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
> SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
> Changed: MRL- PresDet- LinkState-
> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
> RootCap: CRSVisible-
> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: fee0100c Data: 4181
> Capabilities: [90] Subsystem: Lenovo Device 20f3
> Capabilities: [a0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [100 v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed+ WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> Status: NegoPending- InProgress-
> Capabilities: [180 v1] Root Complex Link
> Desc: PortNumber=02 ComponentID=02 EltType=Config
> Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
> Addr: 00000000fed1c000
> Kernel driver in use: pcieport
>
> 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) (prog-if 00 [Normal decode])
> 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, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=05, subordinate=0c, sec-latency=0
> I/O behind bridge: 00002000-00002fff
> Memory behind bridge: f8000000-f9ffffff
> Prefetchable memory behind bridge: 00000000f4000000-00000000f40fffff
> 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] Express (v1) Root Port (Slot+), MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
> ExtTag- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> LnkCap: Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <4us
> ClockPM- Surprise- LLActRep+ BwNot-
> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
> Slot #3, PowerLimit 6.500W; Interlock- NoCompl-
> SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
> Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
> SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
> Changed: MRL- PresDet- LinkState-
> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
> RootCap: CRSVisible-
> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: fee0100c Data: 4189
> Capabilities: [90] Subsystem: Lenovo Device 20f3
> Capabilities: [a0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [100 v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed+ WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> Status: NegoPending- InProgress-
> Capabilities: [180 v1] Root Complex Link
> Desc: PortNumber=04 ComponentID=02 EltType=Config
> Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
> Addr: 00000000fed1c000
> Kernel driver in use: pcieport
>
> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) (prog-if 00 [Normal decode])
> 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, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=0d, subordinate=14, sec-latency=0
> I/O behind bridge: 00003000-00003fff
> Memory behind bridge: fa000000-fbffffff
> Prefetchable memory behind bridge: 00000000f4100000-00000000f41fffff
> 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] Express (v1) Root Port (Slot+), MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
> ExtTag- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> LnkCap: Port #5, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <4us
> ClockPM- Surprise- LLActRep+ BwNot-
> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
> Slot #4, PowerLimit 6.500W; Interlock- NoCompl-
> SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
> Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
> SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
> Changed: MRL- PresDet- LinkState-
> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
> RootCap: CRSVisible-
> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: fee0100c Data: 4191
> Capabilities: [90] Subsystem: Lenovo Device 20f3
> Capabilities: [a0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [100 v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed+ WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> Status: NegoPending- InProgress-
> Capabilities: [180 v1] Root Complex Link
> Desc: PortNumber=05 ComponentID=02 EltType=Config
> Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
> Addr: 00000000fed1c000
> Kernel driver in use: pcieport
>
> 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device 20f0
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 16
> Region 4: I/O ports at 18c0 [size=32]
> Capabilities: [50] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: uhci_hcd
>
> 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device 20f0
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin B routed to IRQ 17
> Region 4: I/O ports at 18e0 [size=32]
> Capabilities: [50] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: uhci_hcd
>
> 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device 20f0
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin C routed to IRQ 18
> Region 4: I/O ports at 1c00 [size=32]
> Capabilities: [50] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: uhci_hcd
>
> 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
> Subsystem: Lenovo Device 20f1
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin D routed to IRQ 19
> Region 0: Memory at fc227000 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
> Capabilities: [58] Debug port: BAR=1 offset=00a0
> Capabilities: [98] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: ehci_hcd
>
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) (prog-if 01 [Subtractive decode])
> 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
> Bus: primary=00, secondary=15, subordinate=18, sec-latency=32
> I/O behind bridge: 00004000-00007fff
> Memory behind bridge: f4800000-f7ffffff
> Prefetchable memory behind bridge: 00000000f0000000-00000000f3ffffff
> Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
> BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Capabilities: [50] Subsystem: Lenovo Device 20f4
>
> 00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
> Subsystem: Lenovo Device 20f5
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Capabilities: [e0] Vendor Specific Information: Len=0c <?>
> Kernel modules: iTCO_wdt
>
> 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0])
> Subsystem: Lenovo Device 20f8
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin B routed to IRQ 44
> Region 0: I/O ports at 1c48 [size=8]
> Region 1: I/O ports at 183c [size=4]
> Region 2: I/O ports at 1c40 [size=8]
> Region 3: I/O ports at 1838 [size=4]
> Region 4: I/O ports at 1c20 [size=32]
> Region 5: Memory at fc226000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: [80] MSI: Enable+ Count=1/16 Maskable- 64bit-
> Address: fee0300c Data: 4199
> Capabilities: [70] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
> Capabilities: [b0] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: ahci
>
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
> Subsystem: Lenovo Device 20f9
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Interrupt: pin A routed to IRQ 23
> Region 0: Memory at fc227400 (64-bit, non-prefetchable) [size=256]
> Region 4: I/O ports at 1c60 [size=32]
> Kernel driver in use: i801_smbus
> Kernel modules: i2c-i801
>
> 03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
> Subsystem: Intel Corporation WiFi Link 5100 AGN
> Physical Slot: 1
> 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, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 48
> Region 0: Memory at f4300000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: [c8] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0100c Data: 41b9
> Capabilities: [e0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <32us
> ClockPM+ Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
> Capabilities: [140 v1] Device Serial Number 00-22-fa-ff-ff-94-43-ea
> Kernel driver in use: iwlwifi
> Kernel modules: iwlwifi
>
> 15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
> Subsystem: Lenovo Device 20c6
> Physical Slot: 1-1
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 168, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 16
> Region 0: Memory at f4800000 (32-bit, non-prefetchable) [size=4K]
> Bus: primary=15, secondary=16, subordinate=17, sec-latency=176
> Memory window 0: f0000000-f3fff000 (prefetchable)
> Memory window 1: c4000000-c7fff000
> I/O window 0: 00004400-000044ff
> I/O window 1: 00004000-000040ff
> BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
> 16-bit legacy interface ports at 0001
> Kernel driver in use: yenta_cardbus
> Kernel modules: yenta_socket
>
> 15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04) (prog-if 10 [OHCI])
> Subsystem: Lenovo Device 20c7
> Physical Slot: 1-1
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 32 (500ns min, 1000ns max), Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 17
> Region 0: Memory at f4801000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME+
> Kernel driver in use: firewire_ohci
> Kernel modules: firewire-ohci
>
> 15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
> Subsystem: Lenovo Device 20c8
> Physical Slot: 1-1
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 32, Cache Line Size: 64 bytes
> Interrupt: pin C routed to IRQ 18
> Region 0: Memory at f4801800 (32-bit, non-prefetchable) [size=256]
> Capabilities: [80] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
> Kernel driver in use: sdhci-pci
> Kernel modules: sdhci-pci
>
> 15:00.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11)
> Subsystem: Lenovo ThinkPad T61
> Physical Slot: 1-1
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 32, Cache Line Size: 64 bytes
> Interrupt: pin C routed to IRQ 18
> Region 0: Memory at f4802000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [80] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
> Kernel driver in use: r592
> Kernel modules: r592
>
> 15:00.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 11)
> Subsystem: Lenovo Device 20cb
> Physical Slot: 1-1
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 32, Cache Line Size: 64 bytes
> Interrupt: pin C routed to IRQ 18
> Region 0: Memory at f4802400 (32-bit, non-prefetchable) [size=256]
> Capabilities: [80] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
> Kernel driver in use: r852
> Kernel modules: r852
>
> [mst@tuck ~]$
> [mst@tuck ~]$ sudo lspci -t
> -[0000:00]-+-00.0
> +-02.0
> +-02.1
> +-03.0
> +-03.3
> +-19.0
> +-1a.0
> +-1a.1
> +-1a.2
> +-1a.7
> +-1b.0
> +-1c.0-[02]--
> +-1c.1-[03]----00.0
> +-1c.3-[05-0c]--
> +-1c.4-[0d-14]--
> +-1d.0
> +-1d.1
> +-1d.2
> +-1d.7
> +-1e.0-[15-18]--+-00.0
> | +-00.1
> | +-00.2
> | +-00.4
> | \-00.5
> +-1f.0
> +-1f.2
> \-1f.3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 14:05 ` Anthony Liguori
@ 2012-06-18 20:36 ` Jason Baron
2012-06-18 21:15 ` Anthony Liguori
0 siblings, 1 reply; 22+ messages in thread
From: Jason Baron @ 2012-06-18 20:36 UTC (permalink / raw)
To: Anthony Liguori
Cc: mst, jan.kiszka, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
On Mon, Jun 18, 2012 at 09:05:17AM -0500, Anthony Liguori wrote:
> On 06/18/2012 08:51 AM, Markus Armbruster wrote:
> >Anthony Liguori<anthony@codemonkey.ws> writes:
> >
> >>On 06/15/2012 02:04 AM, Markus Armbruster wrote:
> >>>Anthony Liguori<anthony@codemonkey.ws> writes:
> >>>
> >>>>On 06/14/2012 02:54 PM, Jason Baron wrote:
> >>>>>Hi,
> >>>>>
> >>>>>I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
> >>>>>seabios trees. On the qemu side, most of the changes revolved around updating
> >>>>>to use QOM and updates to the memory API. I was also able to drop quite a few
> >>>>>patches that had already been resolved by the current qemu tree.
> >>>>>
> >>>>>The trees seem pretty stable and can be found here:
> >>>>>
> >>>>>git://github.com/jibaron/q35-qemu.git
> >>>>>git://github.com/jibaron/q35-seabios.git
> >>>>
> >>>>I'm got the beginnings of a feature page started:
> >>>>
> >>>>http://wiki.qemu.org/Features/Q35
> >>>>
> >>>>The approach above will not work in a QOM world unfortunately. We
> >>>>need to do quite a bit of ground work before adding another chipset.
> >>>>The biggest task is converting devices to not require an ISA bus since
> >>>>ICH9 simply doesn't have an ISA bus.
> >>>
> >>>Could you explain briefly why use of a software ISA bus construct
> >>>matters for device models and/or guests?
> >>
> >>No, but I can provide a long explanation :-)
> >
> >Thanks!
> >
> >>The I440FX has a very basic device topology. The PCI host is the
> >>memory controller and there's a PCI device that happens to have the
> >>SuperI/O chip + a PCI-ISA bridge. There's no IOMMU and interrupt
> >>routing is simple.
> >
> >PC interrupt routing is hardly ever "simple", but I get what you mean ;)
> >
> >>The Q35 is much more sophisticated. The PCI-e complex itself can
> >>present interesting topologies and the legacy PCI bus sits within the
> >>PCI-e complex. You can still have a PCI-ISA bridge but the SuperI/O
> >>chip is not part of it. Rather that's off of a separate bus (the LPC)
> >>which does not logically reside within the PCI-e complex.
> >
> >Let's whether I understand.
> >
> >The platform devices do *not* sit behind a PCI-ISA bridge (in fact, no
> >such bridge exists normally). Instead, they're connected via LPC.
>
> No, *some* platform devices are connected via LPC. Some are not.
>
> To give you an example: both LPC and ISA provide a bus-level DMA
> interface. When you think of IOMMU modeling, it looks something like
> this:
>
> Floppy controller:
> isa_memory_read(isa_dev, ...)
> -> talks to DMA controller
>
> DMA controller:
> Implemented in PIIX4 for I440FX, within ICH9 for q35
> Uses cpu_physical_memory_rw() which takes the get_system() MemoryRegion
>
> So we cannot have the DMA controller be a ISA/LPC device as we do
> today because the ISA bus should only use isa_memory_read() which is
> implemented by the DMA controller. We have an infinite modeling
> loop today :-)
>
I'd like to understand this example better.
I see that DMA_init() is called by pc_basic_device_init(), and used by devices
such as fdc.c and cs4231a.c. So, it appears that the DMA controller is currently
used as an ISA dma controller. However, I don't see that hw/dma.c has explicit
ties to the ISA bus modeling. The current code in hw/fdc.c does:
DMA_read_memory (nchan, fdctrl->fifo + rel_pos,
fdctrl->data_pos, len);
And the rest of interfaces to DMA in isa.h are:
/* dma.c */
int DMA_get_channel_mode (int nchan);
int DMA_read_memory (int nchan, void *buf, int pos, int size);
int DMA_write_memory (int nchan, void *buf, int pos, int size);
void DMA_hold_DREQ (int nchan);
void DMA_release_DREQ (int nchan);
void DMA_schedule(int nchan);
So I don't see a requirement that forces things to be an ISA device to
make use of the DMA controller.
Thanks,
-Jason
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] q35 chipset support
2012-06-18 20:36 ` Jason Baron
@ 2012-06-18 21:15 ` Anthony Liguori
0 siblings, 0 replies; 22+ messages in thread
From: Anthony Liguori @ 2012-06-18 21:15 UTC (permalink / raw)
To: Jason Baron
Cc: mst, jan.kiszka, qemu-devel, Markus Armbruster, yamahata,
alex.williamson
On 06/18/2012 03:36 PM, Jason Baron wrote:
> On Mon, Jun 18, 2012 at 09:05:17AM -0500, Anthony Liguori wrote:
>> On 06/18/2012 08:51 AM, Markus Armbruster wrote:
>>> Anthony Liguori<anthony@codemonkey.ws> writes:
>>>
>>>> On 06/15/2012 02:04 AM, Markus Armbruster wrote:
>>>>> Anthony Liguori<anthony@codemonkey.ws> writes:
>>>>>
>>>>>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>>>>>>> seabios trees. On the qemu side, most of the changes revolved around updating
>>>>>>> to use QOM and updates to the memory API. I was also able to drop quite a few
>>>>>>> patches that had already been resolved by the current qemu tree.
>>>>>>>
>>>>>>> The trees seem pretty stable and can be found here:
>>>>>>>
>>>>>>> git://github.com/jibaron/q35-qemu.git
>>>>>>> git://github.com/jibaron/q35-seabios.git
>>>>>>
>>>>>> I'm got the beginnings of a feature page started:
>>>>>>
>>>>>> http://wiki.qemu.org/Features/Q35
>>>>>>
>>>>>> The approach above will not work in a QOM world unfortunately. We
>>>>>> need to do quite a bit of ground work before adding another chipset.
>>>>>> The biggest task is converting devices to not require an ISA bus since
>>>>>> ICH9 simply doesn't have an ISA bus.
>>>>>
>>>>> Could you explain briefly why use of a software ISA bus construct
>>>>> matters for device models and/or guests?
>>>>
>>>> No, but I can provide a long explanation :-)
>>>
>>> Thanks!
>>>
>>>> The I440FX has a very basic device topology. The PCI host is the
>>>> memory controller and there's a PCI device that happens to have the
>>>> SuperI/O chip + a PCI-ISA bridge. There's no IOMMU and interrupt
>>>> routing is simple.
>>>
>>> PC interrupt routing is hardly ever "simple", but I get what you mean ;)
>>>
>>>> The Q35 is much more sophisticated. The PCI-e complex itself can
>>>> present interesting topologies and the legacy PCI bus sits within the
>>>> PCI-e complex. You can still have a PCI-ISA bridge but the SuperI/O
>>>> chip is not part of it. Rather that's off of a separate bus (the LPC)
>>>> which does not logically reside within the PCI-e complex.
>>>
>>> Let's whether I understand.
>>>
>>> The platform devices do *not* sit behind a PCI-ISA bridge (in fact, no
>>> such bridge exists normally). Instead, they're connected via LPC.
>>
>> No, *some* platform devices are connected via LPC. Some are not.
>>
>> To give you an example: both LPC and ISA provide a bus-level DMA
>> interface. When you think of IOMMU modeling, it looks something like
>> this:
>>
>> Floppy controller:
>> isa_memory_read(isa_dev, ...)
>> -> talks to DMA controller
>>
>> DMA controller:
>> Implemented in PIIX4 for I440FX, within ICH9 for q35
>> Uses cpu_physical_memory_rw() which takes the get_system() MemoryRegion
>>
>> So we cannot have the DMA controller be a ISA/LPC device as we do
>> today because the ISA bus should only use isa_memory_read() which is
>> implemented by the DMA controller. We have an infinite modeling
>> loop today :-)
>>
>
> I'd like to understand this example better.
>
> I see that DMA_init() is called by pc_basic_device_init(), and used by devices
> such as fdc.c and cs4231a.c.
Correct. It also is not modeled as a device at all (yikes!).
I've got a patch that converts dma.c to QOM actually/
> So, it appears that the DMA controller is currently
> used as an ISA dma controller.
Yes.
> However, I don't see that hw/dma.c has explicit
> ties to the ISA bus modeling.
But there should be. DMA is a fundamental part of the ISA specification. The
ISA DMA interface is the only way that an ISA device can read from physical memory.
> The current code in hw/fdc.c does:
>
> DMA_read_memory (nchan, fdctrl->fifo + rel_pos,
> fdctrl->data_pos, len);
>
> And the rest of interfaces to DMA in isa.h are:
>
> /* dma.c */
> int DMA_get_channel_mode (int nchan);
> int DMA_read_memory (int nchan, void *buf, int pos, int size);
> int DMA_write_memory (int nchan, void *buf, int pos, int size);
> void DMA_hold_DREQ (int nchan);
> void DMA_release_DREQ (int nchan);
> void DMA_schedule(int nchan);
>
> So I don't see a requirement that forces things to be an ISA device to
> make use of the DMA controller.
The only way an ISA device can read memory is by using a DMA controller. We
cheat in QEMU today but when trying to model an IOMMU, we cannot get away with
cheating anymore.
Regards,
Anthony Liguori
>
> Thanks,
>
> -Jason
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2012-06-18 21:15 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-14 19:54 [Qemu-devel] q35 chipset support Jason Baron
2012-06-14 20:16 ` Anthony Liguori
2012-06-15 7:04 ` Markus Armbruster
2012-06-15 17:58 ` Anthony Liguori
2012-06-17 8:25 ` Michael S. Tsirkin
2012-06-18 14:16 ` Anthony Liguori
2012-06-18 14:35 ` Michael S. Tsirkin
2012-06-18 15:15 ` Anthony Liguori
2012-06-18 16:04 ` Jason Baron
2012-06-18 13:51 ` Markus Armbruster
2012-06-18 14:05 ` Anthony Liguori
2012-06-18 20:36 ` Jason Baron
2012-06-18 21:15 ` Anthony Liguori
2012-06-18 14:20 ` Michael S. Tsirkin
2012-06-18 14:22 ` Anthony Liguori
2012-06-18 14:37 ` Michael S. Tsirkin
2012-06-18 15:36 ` Andreas Färber
2012-06-18 15:45 ` Anthony Liguori
2012-06-15 17:57 ` Jason Baron
2012-06-15 17:59 ` Anthony Liguori
2012-06-18 13:52 ` Markus Armbruster
2012-06-18 14:38 ` Michael S. Tsirkin
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).