At 11/02/2011 10:15 AM, Isaku Yamahata Write:
> On Tue, Nov 01, 2011 at 04:49:08PM +0800, Wen Congyang wrote:
>> At 11/01/2011 04:44 PM, Michael S. Tsirkin Write:
>>> On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote:
Hi, Michael S. Tsirkin
At 09/26/2011 03:08 PM, Michael
On Tue, Nov 01, 2011 at 04:49:08PM +0800, Wen Congyang wrote:
> At 11/01/2011 04:44 PM, Michael S. Tsirkin Write:
> > On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote:
> >> Hi, Michael S. Tsirkin
> >>
> >> At 09/26/2011 03:08 PM, Michael S. Tsirkin Write:
> >>> On Mon, Sep 26, 2011 at 0
At 11/01/2011 07:48 PM, Michael S. Tsirkin Write:
> On Tue, Nov 01, 2011 at 04:49:08PM +0800, Wen Congyang wrote:
>> At 11/01/2011 04:44 PM, Michael S. Tsirkin Write:
>>> On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote:
Hi, Michael S. Tsirkin
At 09/26/2011 03:08 PM, Mich
On Tue, Nov 01, 2011 at 04:49:08PM +0800, Wen Congyang wrote:
> At 11/01/2011 04:44 PM, Michael S. Tsirkin Write:
> > On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote:
> >> Hi, Michael S. Tsirkin
> >>
> >> At 09/26/2011 03:08 PM, Michael S. Tsirkin Write:
> >>> On Mon, Sep 26, 2011 at 0
At 11/01/2011 04:44 PM, Michael S. Tsirkin Write:
> On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote:
>> Hi, Michael S. Tsirkin
>>
>> At 09/26/2011 03:08 PM, Michael S. Tsirkin Write:
>>> On Mon, Sep 26, 2011 at 02:18:15PM +0800, Wen Congyang wrote:
Hi, Michael S. Tsirkin
>>>
At 09/09/2011 03:34 PM, Michael S. Tsirkin Write:
> On Fri, Sep 09, 2011 at 03:24:54PM +0800, Wen Congyang wrote:
>> At 09/09/2011 03:12 PM, Michael S. Tsirkin Write:
>>> On Fri, Sep 09, 2011 at 02:43:24PM +0800, Wen Congyang wrote:
> However, filtering doesn't work. You could put a BAR outsid
On Fri, Sep 09, 2011 at 03:24:54PM +0800, Wen Congyang wrote:
> At 09/09/2011 03:12 PM, Michael S. Tsirkin Write:
> > On Fri, Sep 09, 2011 at 02:43:24PM +0800, Wen Congyang wrote:
> >>> However, filtering doesn't work. You could put a BAR outside the
> >>> filtered area and it would be visible to
At 09/09/2011 03:12 PM, Michael S. Tsirkin Write:
> On Fri, Sep 09, 2011 at 02:43:24PM +0800, Wen Congyang wrote:
>>> However, filtering doesn't work. You could put a BAR outside the
>>> filtered area and it would be visible to the guest.
>>>
>>
>> I test it on real hardware. If I put a BAR outsid
On Fri, Sep 09, 2011 at 02:43:24PM +0800, Wen Congyang wrote:
> > However, filtering doesn't work. You could put a BAR outside the
> > filtered area and it would be visible to the guest.
> >
>
> I test it on real hardware. If I put a BAR outside the filterer area, and
> then run 'lspci -vv', the
At 08/19/2011 11:26 PM, Avi Kivity Write:
> On 08/18/2011 10:12 PM, Wen Congyang wrote:
>> >>
>> >> The following patch can fix this problem, but I'm not sure whether it
>> >> is right.
>> >
>> > It's correct but insufficient, the filtering code (pci_bridge_filter)
>> > needs to be updated to u
On Thu, Sep 08, 2011 at 07:03:10PM +0800, Wen Congyang wrote:
> At 09/08/2011 06:42 PM, Michael S. Tsirkin Write:
> > On Thu, Sep 08, 2011 at 05:58:12PM +0800, Wen Congyang wrote:
> >> At 09/08/2011 05:43 PM, Gerd Hoffmann Write:
> >>> Hi,
> >>>
> I modify the code like this, and the PCI_INT
At 09/08/2011 06:42 PM, Michael S. Tsirkin Write:
> On Thu, Sep 08, 2011 at 05:58:12PM +0800, Wen Congyang wrote:
>> At 09/08/2011 05:43 PM, Gerd Hoffmann Write:
>>> Hi,
>>>
I modify the code like this, and the PCI_INTERRUPT_LINE register is
set, and I can bind
it to uio_pci_generi
On Thu, Sep 08, 2011 at 05:58:12PM +0800, Wen Congyang wrote:
> At 09/08/2011 05:43 PM, Gerd Hoffmann Write:
> > Hi,
> >
> >> I modify the code like this, and the PCI_INTERRUPT_LINE register is
> >> set, and I can bind
> >> it to uio_pci_generic:
> >
> >> --- a/src/pciinit.c
> >> +++ b/src/pcii
At 09/08/2011 05:43 PM, Gerd Hoffmann Write:
> Hi,
>
>> I modify the code like this, and the PCI_INTERRUPT_LINE register is
>> set, and I can bind
>> it to uio_pci_generic:
>
>> --- a/src/pciinit.c
>> +++ b/src/pciinit.c
>> @@ -575,6 +575,8 @@ static int pci_bios_init_root_regions(u32 start,
>>
Hi,
I modify the code like this, and the PCI_INTERRUPT_LINE register is set, and I
can bind
it to uio_pci_generic:
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -575,6 +575,8 @@ static int pci_bios_init_root_regions(u32 start, u32 end)
pci_bios_init_bus_bases(&busses[0]);
-pci_bi
At 09/08/2011 02:15 PM, Wen Congyang Write:
> At 09/07/2011 07:52 PM, Michael S. Tsirkin Write:
>> On Wed, Sep 07, 2011 at 12:39:09PM +0800, Wen Congyang wrote:
>>> At 09/06/2011 03:45 PM, Avi Kivity Write:
On 09/06/2011 06:06 AM, Wen Congyang wrote:
>> Use the uio driver -
>> http:/
At 09/07/2011 07:52 PM, Michael S. Tsirkin Write:
> On Wed, Sep 07, 2011 at 12:39:09PM +0800, Wen Congyang wrote:
>> At 09/06/2011 03:45 PM, Avi Kivity Write:
>>> On 09/06/2011 06:06 AM, Wen Congyang wrote:
> Use the uio driver -
> http://docs.blackfin.uclinux.org/kernel/generated/uio-how
On Wed, Sep 07, 2011 at 12:39:09PM +0800, Wen Congyang wrote:
> At 09/06/2011 03:45 PM, Avi Kivity Write:
> > On 09/06/2011 06:06 AM, Wen Congyang wrote:
> >> > Use the uio driver -
> >> > http://docs.blackfin.uclinux.org/kernel/generated/uio-howto/. You
> >> just
> >> > mmap() the BAR from use
At 09/06/2011 03:45 PM, Avi Kivity Write:
> On 09/06/2011 06:06 AM, Wen Congyang wrote:
>> > Use the uio driver -
>> > http://docs.blackfin.uclinux.org/kernel/generated/uio-howto/. You
>> just
>> > mmap() the BAR from userspace and play with it.
>>
>> When I try to bind ivshmem to uio_pci_gener
Gerd Hoffmann writes:
> Hi,
>
>>> Looking... qdev_device_help() shows only device properties, not bus
>>> properties. I'd call that a bug.
>>
>> Hmm, but is "bus" a bus property?
>
> It isn't. bus= is handled by qdev core (id= too). addr= actually is
> a (pci) bus property.
bus is indeed t
On 09/06/2011 06:06 AM, Wen Congyang wrote:
> Use the uio driver -
> http://docs.blackfin.uclinux.org/kernel/generated/uio-howto/. You just
> mmap() the BAR from userspace and play with it.
When I try to bind ivshmem to uio_pci_generic, I get the following messages:
uio_pci_generic :01:0
At 09/04/2011 04:25 PM, Avi Kivity Write:
> On 09/02/2011 05:56 AM, Wen Congyang wrote:
>> >
>> > You could use something like kvm-unit-tests.git to write a simple test
>> > that sets up a BAR (say from hw/ivshmem.c), writes and reads to see
>> that
>> > it is visible, programs the bridge to fil
On Mon, Sep 05, 2011 at 11:53:11AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >>Looking... qdev_device_help() shows only device properties, not bus
> >>properties. I'd call that a bug.
> >
> >Hmm, but is "bus" a bus property?
>
> It isn't. bus= is handled by qdev core (id= too). addr= actually
>
Hi,
Looking... qdev_device_help() shows only device properties, not bus
properties. I'd call that a bug.
Hmm, but is "bus" a bus property?
It isn't. bus= is handled by qdev core (id= too). addr= actually is a
(pci) bus property.
cheers,
Gerd
On Mon, Sep 05, 2011 at 10:17:01AM +0200, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Mon, Jul 04, 2011 at 12:43:58PM +0300, Michael S. Tsirkin wrote:
> >> This adds support for a standard pci to pci bridge,
> >> enabling support for more than 32 PCI devices in the system.
>
"Michael S. Tsirkin" writes:
> On Mon, Jul 04, 2011 at 12:43:58PM +0300, Michael S. Tsirkin wrote:
>> This adds support for a standard pci to pci bridge,
>> enabling support for more than 32 PCI devices in the system.
>> To use, specify the device id as a 'bus' option.
>> Example:
>> -device
On 09/04/2011 08:03 PM, Michael S. Tsirkin wrote:
On Sun, Sep 04, 2011 at 07:22:54PM +0300, Avi Kivity wrote:
> On 09/04/2011 07:19 PM, Michael S. Tsirkin wrote:
> >> But isn't it needed? Otherwise why don't vga accesses
> >> alias with a virtio device at 0xc3c0?
> >
> >It really depend
On Mon, Jul 04, 2011 at 12:43:58PM +0300, Michael S. Tsirkin wrote:
> This adds support for a standard pci to pci bridge,
> enabling support for more than 32 PCI devices in the system.
> To use, specify the device id as a 'bus' option.
> Example:
> -device pci-bridge,id=bridge1 \
> -net
On Sun, Sep 04, 2011 at 07:22:54PM +0300, Avi Kivity wrote:
> On 09/04/2011 07:19 PM, Michael S. Tsirkin wrote:
> >> But isn't it needed? Otherwise why don't vga accesses
> >> alias with a virtio device at 0xc3c0?
> >
> >It really depends on the device I think.
> >
>
> It's probably the bus. I
On 09/04/2011 07:19 PM, Michael S. Tsirkin wrote:
> But isn't it needed? Otherwise why don't vga accesses
> alias with a virtio device at 0xc3c0?
It really depends on the device I think.
It's probably the bus. ISA may not decode A10-15, but if the pci/isa
bridge does, then it doesn't mat
On Sun, Sep 04, 2011 at 06:49:34PM +0300, Avi Kivity wrote:
> On 09/04/2011 06:46 PM, Michael S. Tsirkin wrote:
> >>
> >> Why pointers? Regular fields require less upkeep.
> >
> >Good point. Why does PIIX use pointers? I just copied that ...
> >
>
> It doesn't, at least not completely:
>
>
> s
On Sun, Sep 04, 2011 at 06:46:46PM +0300, Avi Kivity wrote:
> On 09/04/2011 06:45 PM, Michael S. Tsirkin wrote:
> >On Sun, Sep 04, 2011 at 06:37:08PM +0300, Avi Kivity wrote:
> >> On 09/04/2011 06:24 PM, Michael S. Tsirkin wrote:
> >> >>
> >> >> Of course it doesn't ignore it. See the 440fx i
On 09/04/2011 06:46 PM, Michael S. Tsirkin wrote:
>
> Why pointers? Regular fields require less upkeep.
Good point. Why does PIIX use pointers? I just copied that ...
It doesn't, at least not completely:
struct PCII440FXState {
PCIDevice dev;
MemoryRegion *system_memory;
Memor
On 09/04/2011 06:45 PM, Michael S. Tsirkin wrote:
On Sun, Sep 04, 2011 at 06:37:08PM +0300, Avi Kivity wrote:
> On 09/04/2011 06:24 PM, Michael S. Tsirkin wrote:
> >>
> >> Of course it doesn't ignore it. See the 440fx implementation, if
> >> you disable VGA access (via the SMRAM register
On Sun, Sep 04, 2011 at 06:42:42PM +0300, Avi Kivity wrote:
> On 09/04/2011 06:26 PM, Michael S. Tsirkin wrote:
> >On Sun, Sep 04, 2011 at 05:36:56PM +0300, Avi Kivity wrote:
> >> So long as we're nitpicking ...
> >
> >+static void pci_bridge_init_alias(PCIBridge *bridge, MemoryRegion *alias,
> >+
On Sun, Sep 04, 2011 at 06:37:08PM +0300, Avi Kivity wrote:
> On 09/04/2011 06:24 PM, Michael S. Tsirkin wrote:
> >>
> >> Of course it doesn't ignore it. See the 440fx implementation, if
> >> you disable VGA access (via the SMRAM register), vga goes away.
> >
> >Yes but that's for VGA RAM, right
On 09/04/2011 06:26 PM, Michael S. Tsirkin wrote:
On Sun, Sep 04, 2011 at 05:36:56PM +0300, Avi Kivity wrote:
> So long as we're nitpicking ...
+static void pci_bridge_init_alias(PCIBridge *bridge, MemoryRegion *alias,
+ uint8_t type, const char *name,
+
On 09/04/2011 06:24 PM, Michael S. Tsirkin wrote:
>
> Of course it doesn't ignore it. See the 440fx implementation, if
> you disable VGA access (via the SMRAM register), vga goes away.
Yes but that's for VGA RAM, right? I'm talking about the IO addresses:
are tons of aliases created as you su
On Sun, Sep 04, 2011 at 05:36:56PM +0300, Avi Kivity wrote:
> So long as we're nitpicking ...
OK, this should do it then.
diff --git a/hw/pci.c b/hw/pci.c
index 57ff7b1..56dfa18 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -889,7 +889,6 @@ void pci_register_bar(PCIDevice *pci_dev, int region_num,
On Sun, Sep 04, 2011 at 06:14:22PM +0300, Avi Kivity wrote:
> On 09/04/2011 05:54 PM, Michael S. Tsirkin wrote:
> >> Way too late. And also won't work, since often the offset is
> >> determined by one party and the size by another.
> >
> >For things like BARs, yes - but these don't need to be
>
On 09/04/2011 05:54 PM, Michael S. Tsirkin wrote:
> Way too late. And also won't work, since often the offset is
> determined by one party and the size by another.
For things like BARs, yes - but these don't need to be
that big normally. We could add an additinal API
that gets first/last para
On Sun, Sep 04, 2011 at 05:36:56PM +0300, Avi Kivity wrote:
> On 09/04/2011 05:21 PM, Michael S. Tsirkin wrote:
> >> >
> >> >+static pcibus_t pci_bridge_get_size(const PCIDevice *bridge, uint8_t
> >> type)
> >> >+{
> >> >+return pci_bridge_get_limit(bridge, type)>=
> >> >+pci_brid
On 09/04/2011 05:21 PM, Michael S. Tsirkin wrote:
> >
> >+static pcibus_t pci_bridge_get_size(const PCIDevice *bridge, uint8_t type)
> >+{
> >+return pci_bridge_get_limit(bridge, type)>=
> >+pci_bridge_get_base(bridge, type) ?
> >+pci_bridge_get_limit(bridge, type) -
>
On Sun, Sep 04, 2011 at 04:55:33PM +0300, Avi Kivity wrote:
> On 09/04/2011 04:41 PM, Michael S. Tsirkin wrote:
> >On Sun, Sep 04, 2011 at 04:05:14PM +0300, Avi Kivity wrote:
> >> It follows naturally:
> >
> >OK, so it seems the following is more or less what you suggest?
> >I'm not sure I create/
On 09/04/2011 04:41 PM, Michael S. Tsirkin wrote:
On Sun, Sep 04, 2011 at 04:05:14PM +0300, Avi Kivity wrote:
> It follows naturally:
OK, so it seems the following is more or less what you suggest?
I'm not sure I create/destroy subregions properly.
Both the alias and the subregion get the same
On Sun, Sep 04, 2011 at 04:05:14PM +0300, Avi Kivity wrote:
> It follows naturally:
OK, so it seems the following is more or less what you suggest?
I'm not sure I create/destroy subregions properly.
Both the alias and the subregion get the same start value?
Is the region name for debugging only?
W
On 09/04/2011 04:05 PM, Avi Kivity wrote:
It follows naturally:
system_memory
|
+--- pci0_alias0 (aliases part of pci0)
|
pci0 <-+
The pointer from pci0_alias to pci0 looked a lot better when I drew it.
--
error compiling committee.c: too many arguments to function
On 09/04/2011 04:01 PM, Michael S. Tsirkin wrote:
On Sun, Sep 04, 2011 at 03:40:58PM +0300, Avi Kivity wrote:
> On 09/04/2011 03:30 PM, Michael S. Tsirkin wrote:
> >>
> >> Create a memory region for the bridge's address space. This region
> >> is not directly added to system_memory or it
On Sun, Sep 04, 2011 at 03:40:58PM +0300, Avi Kivity wrote:
> On 09/04/2011 03:30 PM, Michael S. Tsirkin wrote:
> >>
> >> Create a memory region for the bridge's address space. This region
> >> is not directly added to system_memory or its descendants.
> >
> >I do this for each bridge in the hie
On 09/04/2011 03:30 PM, Michael S. Tsirkin wrote:
>
> Create a memory region for the bridge's address space. This region
> is not directly added to system_memory or its descendants.
I do this for each bridge in the hierarchy, right?
Each bridge does this independently (so yes).
> fx440 d
On Sun, Aug 28, 2011 at 04:53:33PM +0300, Avi Kivity wrote:
> On 08/28/2011 04:42 PM, Michael S. Tsirkin wrote:
> >On Sun, Aug 28, 2011 at 04:10:14PM +0300, Avi Kivity wrote:
> >> On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote:
> >> >>
> >> >> If it really matters, you can add a prefetchabil
On 09/02/2011 05:56 AM, Wen Congyang wrote:
>
> You could use something like kvm-unit-tests.git to write a simple test
> that sets up a BAR (say from hw/ivshmem.c), writes and reads to see that
> it is visible, programs the bridge to filter part of the BAR out, then
> writes and reads again t
At 08/22/2011 02:23 PM, Avi Kivity Write:
> On 08/22/2011 06:13 AM, Wen Congyang wrote:
>> At 08/19/2011 11:26 PM, Avi Kivity Write:
>> > On 08/18/2011 10:12 PM, Wen Congyang wrote:
>> >> >>
>> >> >> The following patch can fix this problem, but I'm not sure
>> whether it
>> >> >> is right.
At 08/22/2011 02:23 PM, Avi Kivity Write:
> On 08/22/2011 06:13 AM, Wen Congyang wrote:
>> At 08/19/2011 11:26 PM, Avi Kivity Write:
>> > On 08/18/2011 10:12 PM, Wen Congyang wrote:
>> >> >>
>> >> >> The following patch can fix this problem, but I'm not sure
>> whether it
>> >> >> is right.
On 08/28/2011 04:42 PM, Michael S. Tsirkin wrote:
On Sun, Aug 28, 2011 at 04:10:14PM +0300, Avi Kivity wrote:
> On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote:
> >>
> >> If it really matters, you can add a prefetchability attribute to
> >> MemoryRegions. Does it though?
> >
> >Well,
On Sun, Aug 28, 2011 at 04:10:14PM +0300, Avi Kivity wrote:
> On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote:
> >>
> >> If it really matters, you can add a prefetchability attribute to
> >> MemoryRegions. Does it though?
> >
> >Well, its another one of these things that
> >guests *probably* wo
On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote:
>
> If it really matters, you can add a prefetchability attribute to
> MemoryRegions. Does it though?
Well, its another one of these things that
guests *probably* won't in practice use.
But I don't see a way to be sure.
If the guest puts a pr
On Sun, Aug 28, 2011 at 10:50:49AM +0300, Avi Kivity wrote:
> On 08/26/2011 12:43 PM, Michael S. Tsirkin wrote:
> >On Thu, Aug 18, 2011 at 08:15:43AM -0700, Avi Kivity wrote:
> >> It's correct but insufficient, the filtering code
> >> (pci_bridge_filter) needs to be updated to use the memory API.
On 08/26/2011 12:43 PM, Michael S. Tsirkin wrote:
On Thu, Aug 18, 2011 at 08:15:43AM -0700, Avi Kivity wrote:
> It's correct but insufficient, the filtering code
> (pci_bridge_filter) needs to be updated to use the memory API.
>
> Basically it gets simpler and correcter.
I've been struggling
On Thu, Aug 18, 2011 at 11:22:31AM +0800, Wen Congyang wrote:
> >From 3cee5a14f0ff7aeac148f9416eac6fa7c6ca Mon Sep 17 00:00:00 2001
> From: Wen Congyang
> Date: Thu, 18 Aug 2011 09:33:19 +0800
> Subject: [PATCH] PCI_Bridge: use parent bus's address space
>
> The pci device may call pci_regist
On Thu, Aug 18, 2011 at 08:15:43AM -0700, Avi Kivity wrote:
> It's correct but insufficient, the filtering code
> (pci_bridge_filter) needs to be updated to use the memory API.
>
> Basically it gets simpler and correcter.
I've been struggling with the following problem: bridges have two memory
ra
On 08/22/2011 06:13 AM, Wen Congyang wrote:
At 08/19/2011 11:26 PM, Avi Kivity Write:
> On 08/18/2011 10:12 PM, Wen Congyang wrote:
>> >>
>> >> The following patch can fix this problem, but I'm not sure whether it
>> >> is right.
>> >
>> > It's correct but insufficient, the filtering
At 08/19/2011 11:26 PM, Avi Kivity Write:
> On 08/18/2011 10:12 PM, Wen Congyang wrote:
>> >>
>> >> The following patch can fix this problem, but I'm not sure whether it
>> >> is right.
>> >
>> > It's correct but insufficient, the filtering code (pci_bridge_filter)
>> > needs to be updated to u
On 08/18/2011 10:12 PM, Wen Congyang wrote:
>>
>> The following patch can fix this problem, but I'm not sure whether it
>> is right.
>
> It's correct but insufficient, the filtering code (pci_bridge_filter)
> needs to be updated to use the memory API.
I read the function pci_bridge_filter(),
At 08/18/2011 11:15 PM, Avi Kivity Write:
> On 08/17/2011 08:22 PM, Wen Congyang wrote:
>> At 08/17/2011 04:37 PM, Wen Congyang Write:
>> > At 07/04/2011 05:43 PM, Michael S. Tsirkin Write:
>> >> This adds support for a standard pci to pci bridge,
>> >> enabling support for more than 32 PCI devi
On 08/17/2011 08:22 PM, Wen Congyang wrote:
At 08/17/2011 04:37 PM, Wen Congyang Write:
> At 07/04/2011 05:43 PM, Michael S. Tsirkin Write:
>> This adds support for a standard pci to pci bridge,
>> enabling support for more than 32 PCI devices in the system.
>> To use, specify the device id a
At 08/17/2011 04:37 PM, Wen Congyang Write:
> At 07/04/2011 05:43 PM, Michael S. Tsirkin Write:
>> This adds support for a standard pci to pci bridge,
>> enabling support for more than 32 PCI devices in the system.
>> To use, specify the device id as a 'bus' option.
>> Example:
>> -device pci-
At 07/04/2011 05:43 PM, Michael S. Tsirkin Write:
> This adds support for a standard pci to pci bridge,
> enabling support for more than 32 PCI devices in the system.
> To use, specify the device id as a 'bus' option.
> Example:
> -device pci-bridge,id=bridge1 \
> -netdev user,id=u \
>
On Tue, Jul 05, 2011 at 10:29:36PM +0900, Isaku Yamahata wrote:
> On Mon, Jul 04, 2011 at 12:43:59PM +0300, Michael S. Tsirkin wrote:
> > +/* Mapping mandated by PCI-to-PCI Bridge architecture specification,
> > + * revision 1.2 */
> > +/* Table 9-1: Interrupt Binding for Devices Behind a Bridge */
On Mon, Jul 04, 2011 at 12:43:59PM +0300, Michael S. Tsirkin wrote:
> +/* Mapping mandated by PCI-to-PCI Bridge architecture specification,
> + * revision 1.2 */
> +/* Table 9-1: Interrupt Binding for Devices Behind a Bridge */
> +static int pci_bridge_dev_map_irq_fn(PCIDevice *dev, int irq_num)
>
This adds support for a standard pci to pci bridge,
enabling support for more than 32 PCI devices in the system.
To use, specify the device id as a 'bus' option.
Example:
-device pci-bridge,id=bridge1 \
-netdev user,id=u \
-device ne2k_pci,id=net2,bus=bridge1,netdev=u
TODO:
71 matches
Mail list logo
