On 29/01/2015 15:25, Peter Maydell wrote:
> > Ah, right, I forgot about that. Unfortunately I can't reserve PCI IDs in
> > the Red Hat PCI range.
> >
> > Michael, what's the process here?
>
> Last time this came up I think Paolo said the official registration
> was getting a patch into QEMU maste
On 29 January 2015 at 13:59, Alexander Graf wrote:
> On 27.01.15 16:31, Peter Maydell wrote:
>> On 21 January 2015 at 16:18, Alexander Graf wrote:
>>> +dc->vmsd = &vmstate_gpex_root;
>>> +k->vendor_id = PCI_VENDOR_ID_REDHAT;
>>> +k->device_id = PCI_DEVICE_ID_REDHAT_BRIDGE;
>>
>> Prett
On 27.01.15 16:31, Peter Maydell wrote:
> On 21 January 2015 at 16:18, Alexander Graf wrote:
>> With simple exposure of MMFG, ioport window, mmio window and an IRQ line we
>
> Four :-)
>
>> can successfully create a workable PCIe host bridge that can be mapped
>> anywhere
>> and only needs to
On 21 January 2015 at 16:18, Alexander Graf wrote:
> With simple exposure of MMFG, ioport window, mmio window and an IRQ line we
Four :-)
> can successfully create a workable PCIe host bridge that can be mapped
> anywhere
> and only needs to get described to the OS using whatever means it likes
Looks that you forgot the "single legacy IRQ line" comment from v1.
-Mike
On 01/21/2015 06:18 PM, Alexander Graf wrote:
With simple exposure of MMFG, ioport window, mmio window and an IRQ line we
can successfully create a workable PCIe host bridge that can be mapped anywhere
and only needs to g
With simple exposure of MMFG, ioport window, mmio window and an IRQ line we
can successfully create a workable PCIe host bridge that can be mapped anywhere
and only needs to get described to the OS using whatever means it likes.
This patch implements such a "generic" host bridge. It only supports
