Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge for IGD passthrough

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.05.13 at 17:52, "G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Feb 8, 2013 at 7:48 PM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> On Fri, 8 Feb 2013, Jan Beulich wrote:
>>> >>> On 08.02.13 at 12:30, Stefano Stabellini 
>>> >>> <stefano.stabellini@xxxxxxxxxxxxx>
>>> wrote:
>>> > On Thu, 7 Feb 2013, G.R. wrote:
>>> >> >
>>> >> > For one I wonder whether this is really _always_ correct. I.e.
>>> >> > the device at 00:1f.0 always being an ISA bridge. Wouldn't it
>>> >> > be better to mirror whatever the host device says?
>>> >> >
>>> >> >From the Intel driver code, it's looking for an intel ISA bridge.
>>> >> So your question would be should it be always at 00:1f.0.
>>> >> So far it seems that it is.
>>> >>
>>> >> > And then I don't see why you need to open code all of
>>> >> > pci_bridge_init() instead of just overriding the class value after
>>> >> > you called that function (or, if the order of events for some
>>> >> > reason matters, adding another parameter to the function).
>>> >>
>>> >> Stefano, could you comment? It's your code after all.
>>> >
>>> > It's not trivial because PCIBus is defined in hw/pci.c, so you can't
>>> > dereference members of PCIBus from hw/pt-graphics.c.
>>>
>>> But the patch makes it so the structure itself becomes public?
>>> What problem do you see?
>>
>> QEMU's include chain can be devious at times but I have no objections in
>> making PCIBus public.
> 
> Are you talking about making PCIBus public (to hw/pci.h) and change
> the code to something like this:
> 
>     if (vid == PCI_VENDOR_ID_INTEL) {
>         PCIBus *s = pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
>                                        pch_map_irq, "intel_bridge_1f");
> 
>         pci_config_set_class(s->parent_dev.config, PCI_CLASS_BRIDGE_ISA);
>         s->parent_dev.config[PCI_HEADER_TYPE] = 0x80;
>     }

Along those lines, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel