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

The i915 driver probes chip version through PCH ISA bridge device / vendor ID.
Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in qemu-xen-trad,
which breaks the assumption of the driver. This change fixes the issue by
correctly exposing the ISA bridge to domU.

Note the PIIX3 ISA bridge is still present on the bus (dropping it seems
break qemu all-together), i915 driver still need to be updated to handle this.

Change since last version:
  1. Introduce helper function to avoid exposing PCI_Bus / PCI_Bridge
definition to public.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
               Rui Guo <firemeteor@users.sourceforge.net>
Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135548433715750
---
 hw/pci.c         |   10 ++++++++++
 hw/pci.h         |    3 +++
 hw/pt-graphics.c |    9 ++++++---
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index f051de1..c423285 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -938,6 +938,16 @@ PCIBus *pci_bridge_init(PCIBus *bus, int devfn,
uint16_t vid, uint16_t did,
     return s->bus;
 }

+PCIBus *pci_isa_bridge_init(PCIBus *bus, int devfn, uint16_t vid, uint16_t did,
+                            uint8_t rid, pci_map_irq_fn map_irq,
const char *name)
+{
+    PCIBus *s = pci_bridge_init(bus, devfn, vid, did, rid, map_irq, name);
+
+    pci_config_set_class(s->parent_dev->config, PCI_CLASS_BRIDGE_ISA);
+    s->parent_dev->config[PCI_HEADER_TYPE] = 0x80;
+    return s;
+}
+
 int pt_chk_bar_overlap(PCIBus *bus, int devfn, uint32_t addr,
                         uint32_t size, uint8_t type)
 {
diff --git a/hw/pci.h b/hw/pci.h
index edc58b6..cacbdd2 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -271,6 +271,9 @@ void pci_info(void);
 PCIBus *pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid, uint16_t did,
                         uint8_t rid, pci_map_irq_fn map_irq, const char *name);

+PCIBus *pci_isa_bridge_init(PCIBus *bus, int devfn, uint16_t vid, uint16_t did,
+                            uint8_t rid, pci_map_irq_fn map_irq,
const char *name);
+
 #define NR_PCI_FUNC          8
 #define NR_PCI_DEV           32
 #define NR_PCI_DEVFN         (NR_PCI_FUNC * NR_PCI_DEV)
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index c6f8869..7302b25 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -3,6 +3,7 @@
  */

 #include "pass-through.h"
+#include "pci.h"
 #include "pci/header.h"
 #include "pci/pci.h"

@@ -40,9 +41,11 @@ void intel_pch_init(PCIBus *bus)
     did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
     rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);

-    if ( vid == PCI_VENDOR_ID_INTEL )
-        pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
-                        pch_map_irq, "intel_bridge_1f");
+    if (vid == PCI_VENDOR_ID_INTEL) {
+        pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
+                            pch_map_irq, "intel_bridge_1f");
+
+    }
 }

 uint32_t igd_read_opregion(struct pt_dev *pci_dev)
--
1.7.10.4

>>> On 17.06.13 at 14:42, "G.R."
<firemeteor@users.sourceforge.net> wrote:
> The i915 driver probes chip version through PCH ISA bridge device / vendor 
> ID.
> Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in
qemu-xen-trad,
> which breaks the assumption of the driver. This change fixes the issue by
> correctly exposing the ISA bridge to domU.
> 
> Note the PIIX3 ISA bridge is still present on the bus (dropping it seems
> break qemu all-together), i915 driver still need to be updated to handle 
> this.
> 
> Change since last version:
>   1. Introduce helper function to avoid exposing PCI_Bus / PCI_Bridge
> definition to public.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
>                Rui Guo <firemeteor@users.sourceforge.net>
> Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
I''m fine with this version, but does the above indeed reflect
reality? I.e. wasn''t it you who wrote the patch in its current
form?

Jan
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -938,6 +938,16 @@ PCIBus *pci_bridge_init(PCIBus *bus, int devfn,
> uint16_t vid, uint16_t did,
>      return s->bus;
>  }
> 
> +PCIBus *pci_isa_bridge_init(PCIBus *bus, int devfn, uint16_t vid, uint16_t
did,
> +                            uint8_t rid, pci_map_irq_fn map_irq, const
char *name)
> +{
> +    PCIBus *s = pci_bridge_init(bus, devfn, vid, did, rid, map_irq, name);
> +
> +    pci_config_set_class(s->parent_dev->config,
PCI_CLASS_BRIDGE_ISA);
> +    s->parent_dev->config[PCI_HEADER_TYPE] = 0x80;
> +    return s;
> +}
> +
>  int pt_chk_bar_overlap(PCIBus *bus, int devfn, uint32_t addr,
>                          uint32_t size, uint8_t type)
>  {
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -271,6 +271,9 @@ void pci_info(void);
>  PCIBus *pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid, uint16_t
did,
>                          uint8_t rid, pci_map_irq_fn map_irq, const char
*name);
> 
> +PCIBus *pci_isa_bridge_init(PCIBus *bus, int devfn, uint16_t vid, uint16_t
did,
> +                            uint8_t rid, pci_map_irq_fn map_irq, const
char *name);
> +
>  #define NR_PCI_FUNC          8
>  #define NR_PCI_DEV           32
>  #define NR_PCI_DEVFN         (NR_PCI_FUNC * NR_PCI_DEV)
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -3,6 +3,7 @@
>   */
> 
>  #include "pass-through.h"
> +#include "pci.h"
>  #include "pci/header.h"
>  #include "pci/pci.h"
> 
> @@ -40,9 +41,11 @@ void intel_pch_init(PCIBus *bus)
>      did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>      rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
> 
> -    if ( vid == PCI_VENDOR_ID_INTEL )
> -        pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
> -                        pch_map_irq, "intel_bridge_1f");
> +    if (vid == PCI_VENDOR_ID_INTEL) {
> +        pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
> +                            pch_map_irq, "intel_bridge_1f");
> +
> +    }
>  }
> 
>  uint32_t igd_read_opregion(struct pt_dev *pci_dev)

On Mon, Jun 17, 2013 at 8:54 PM, Jan Beulich <JBeulich@suse.com>
wrote:
>>>> On 17.06.13 at 14:42, "G.R."
<firemeteor@users.sourceforge.net> wrote:
>> The i915 driver probes chip version through PCH ISA bridge device /
vendor
>> ID.
>> Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in
qemu-xen-trad,
>> which breaks the assumption of the driver. This change fixes the issue
by
>> correctly exposing the ISA bridge to domU.
>>
>> Note the PIIX3 ISA bridge is still present on the bus (dropping it
seems
>> break qemu all-together), i915 driver still need to be updated to
handle
>> this.
>>
>> Change since last version:
>>   1. Introduce helper function to avoid exposing PCI_Bus / PCI_Bridge
>> definition to public.
>>
>> Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>,
>>                Rui Guo <firemeteor@users.sourceforge.net>
>> Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
>
> I''m fine with this version, but does the above indeed reflect
> reality? I.e. wasn''t it you who wrote the patch in its current
> form?
>
Ah! Thanks for pointing this out...
I just keep carrying this sign-off lines from the original version.
So I think I should use these lines for signing-off:
 Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net>
 Tested-by: Rui Guo <firemeteor@users.sourceforge.net>

Do I need to resend the whole thing out?

Rui
> Jan
>
>> --- a/hw/pci.c
>> +++ b/hw/pci.c
>> @@ -938,6 +938,16 @@ PCIBus *pci_bridge_init(PCIBus *bus, int devfn,
>> uint16_t vid, uint16_t did,
>>      return s->bus;
>>  }
>>
>> +PCIBus *pci_isa_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
uint16_t did,
>> +                            uint8_t rid, pci_map_irq_fn map_irq, const
char *name)
>> +{
>> +    PCIBus *s = pci_bridge_init(bus, devfn, vid, did, rid, map_irq,
name);
>> +
>> +    pci_config_set_class(s->parent_dev->config,
PCI_CLASS_BRIDGE_ISA);
>> +    s->parent_dev->config[PCI_HEADER_TYPE] = 0x80;
>> +    return s;
>> +}
>> +
>>  int pt_chk_bar_overlap(PCIBus *bus, int devfn, uint32_t addr,
>>                          uint32_t size, uint8_t type)
>>  {
>> --- a/hw/pci.h
>> +++ b/hw/pci.h
>> @@ -271,6 +271,9 @@ void pci_info(void);
>>  PCIBus *pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid, uint16_t
did,
>>                          uint8_t rid, pci_map_irq_fn map_irq, const
char *name);
>>
>> +PCIBus *pci_isa_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
uint16_t did,
>> +                            uint8_t rid, pci_map_irq_fn map_irq, const
char *name);
>> +
>>  #define NR_PCI_FUNC          8
>>  #define NR_PCI_DEV           32
>>  #define NR_PCI_DEVFN         (NR_PCI_FUNC * NR_PCI_DEV)
>> --- a/hw/pt-graphics.c
>> +++ b/hw/pt-graphics.c
>> @@ -3,6 +3,7 @@
>>   */
>>
>>  #include "pass-through.h"
>> +#include "pci.h"
>>  #include "pci/header.h"
>>  #include "pci/pci.h"
>>
>> @@ -40,9 +41,11 @@ void intel_pch_init(PCIBus *bus)
>>      did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>>      rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
>>
>> -    if ( vid == PCI_VENDOR_ID_INTEL )
>> -        pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
>> -                        pch_map_irq, "intel_bridge_1f");
>> +    if (vid == PCI_VENDOR_ID_INTEL) {
>> +        pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
>> +                            pch_map_irq, "intel_bridge_1f");
>> +
>> +    }
>>  }
>>
>>  uint32_t igd_read_opregion(struct pt_dev *pci_dev)
>
>

On Mon, 17 Jun 2013, G.R. wrote:
> On Mon, Jun 17, 2013 at 8:54 PM, Jan Beulich <JBeulich@suse.com>
wrote:
> >>>> On 17.06.13 at 14:42, "G.R."
<firemeteor@users.sourceforge.net> wrote:
> >> The i915 driver probes chip version through PCH ISA bridge device
/ vendor
> >> ID.
> >> Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in
qemu-xen-trad,
> >> which breaks the assumption of the driver. This change fixes the
issue by
> >> correctly exposing the ISA bridge to domU.
> >>
> >> Note the PIIX3 ISA bridge is still present on the bus (dropping it
seems
> >> break qemu all-together), i915 driver still need to be updated to
handle
> >> this.
> >>
> >> Change since last version:
> >>   1. Introduce helper function to avoid exposing PCI_Bus /
PCI_Bridge
> >> definition to public.
> >>
> >> Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>,
> >>                Rui Guo <firemeteor@users.sourceforge.net>
> >> Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
> >
> > I''m fine with this version, but does the above indeed reflect
> > reality? I.e. wasn''t it you who wrote the patch in its
current
> > form?
> >
> 
> Ah! Thanks for pointing this out...
> I just keep carrying this sign-off lines from the original version.
> So I think I should use these lines for signing-off:
>  Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net>
>  Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
> 
> Do I need to resend the whole thing out?
I think it''s OK and Ian should be able to change those lines for you

On Thu, Jun 20, 2013 at 9:31 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 17 Jun 2013, G.R. wrote:
>> On Mon, Jun 17, 2013 at 8:54 PM, Jan Beulich <JBeulich@suse.com>
wrote:
>> >>>> On 17.06.13 at 14:42, "G.R."
<firemeteor@users.sourceforge.net> wrote:
>> >> The i915 driver probes chip version through PCH ISA bridge
device / vendor
>> >> ID.
>> >> Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in
qemu-xen-trad,
>> >> which breaks the assumption of the driver. This change fixes
the issue by
>> >> correctly exposing the ISA bridge to domU.
>> >>
>> >> Note the PIIX3 ISA bridge is still present on the bus
(dropping it seems
>> >> break qemu all-together), i915 driver still need to be updated
to handle
>> >> this.
>> >>
>> >> Change since last version:
>> >>   1. Introduce helper function to avoid exposing PCI_Bus /
PCI_Bridge
>> >> definition to public.
>> >>
>> >> Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>,
>> >>                Rui Guo
<firemeteor@users.sourceforge.net>
>> >> Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
>> >
>> > I''m fine with this version, but does the above indeed
reflect
>> > reality? I.e. wasn''t it you who wrote the patch in its
current
>> > form?
>> >
>>
>> Ah! Thanks for pointing this out...
>> I just keep carrying this sign-off lines from the original version.
>> So I think I should use these lines for signing-off:
>>  Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net>
>>  Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
>>
>> Do I need to resend the whole thing out?
>
> I think it''s OK and Ian should be able to change those lines for
you
>
Thanks!
PS: I finally have i915 driver maintainer accepted my patch about the
pch detection.
So together with this patch, it would produce a working ouf-of-box linux
set.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On Fri, Jun 21, 2013 at 09:25:49AM +0800, G.R. wrote:
> On Thu, Jun 20, 2013 at 9:31 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 17 Jun 2013, G.R. wrote:
> >> On Mon, Jun 17, 2013 at 8:54 PM, Jan Beulich
<JBeulich@suse.com> wrote:
> >> >>>> On 17.06.13 at 14:42, "G.R."
<firemeteor@users.sourceforge.net> wrote:
> >> >> The i915 driver probes chip version through PCH ISA
bridge device / vendor
> >> >> ID.
> >> >> Previously, the PCH ISA bridge is exposed as PCI-PCI
bridge in qemu-xen-trad,
> >> >> which breaks the assumption of the driver. This change
fixes the issue by
> >> >> correctly exposing the ISA bridge to domU.
> >> >>
> >> >> Note the PIIX3 ISA bridge is still present on the bus
(dropping it seems
> >> >> break qemu all-together), i915 driver still need to be
updated to handle
> >> >> this.
> >> >>
> >> >> Change since last version:
> >> >>   1. Introduce helper function to avoid exposing PCI_Bus
/ PCI_Bridge
> >> >> definition to public.
> >> >>
> >> >> Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>,
> >> >>                Rui Guo
<firemeteor@users.sourceforge.net>
> >> >> Tested-by: Rui Guo
<firemeteor@users.sourceforge.net>
> >> >
> >> > I''m fine with this version, but does the above
indeed reflect
> >> > reality? I.e. wasn''t it you who wrote the patch in
its current
> >> > form?
> >> >
> >>
> >> Ah! Thanks for pointing this out...
> >> I just keep carrying this sign-off lines from the original
version.
> >> So I think I should use these lines for signing-off:
> >>  Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net>
> >>  Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
> >>
> >> Do I need to resend the whole thing out?
> >
> > I think it''s OK and Ian should be able to change those lines
for you
> >
> Thanks!
> PS: I finally have i915 driver maintainer accepted my patch about the
> pch detection.
Nice. Which one was it? Do you have a URL for it?

Thanks!
> So together with this patch, it would produce a working ouf-of-box linux
set.
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

On Sat, Jun 22, 2013 at 2:01 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Jun 21, 2013 at 09:25:49AM +0800, G.R. wrote:
>> On Thu, Jun 20, 2013 at 9:31 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Mon, 17 Jun 2013, G.R. wrote:
>> >> On Mon, Jun 17, 2013 at 8:54 PM, Jan Beulich
<JBeulich@suse.com> wrote:
>> >> >>>> On 17.06.13 at 14:42, "G.R."
<firemeteor@users.sourceforge.net> wrote:
>> >> >> The i915 driver probes chip version through PCH ISA
bridge device / vendor
>> >> >> ID.
>> >> >> Previously, the PCH ISA bridge is exposed as PCI-PCI
bridge in qemu-xen-trad,
>> >> >> which breaks the assumption of the driver. This
change fixes the issue by
>> >> >> correctly exposing the ISA bridge to domU.
>> >> >>
>> >> >> Note the PIIX3 ISA bridge is still present on the bus
(dropping it seems
>> >> >> break qemu all-together), i915 driver still need to
be updated to handle
>> >> >> this.
>> >> >>
>> >> >> Change since last version:
>> >> >>   1. Introduce helper function to avoid exposing
PCI_Bus / PCI_Bridge
>> >> >> definition to public.
>> >> >>
>> >> >> Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>,
>> >> >>                Rui Guo
<firemeteor@users.sourceforge.net>
>> >> >> Tested-by: Rui Guo
<firemeteor@users.sourceforge.net>
>> >> >
>> >> > I''m fine with this version, but does the above
indeed reflect
>> >> > reality? I.e. wasn''t it you who wrote the patch
in its current
>> >> > form?
>> >> >
>> >>
>> >> Ah! Thanks for pointing this out...
>> >> I just keep carrying this sign-off lines from the original
version.
>> >> So I think I should use these lines for signing-off:
>> >>  Signed-off-by: Rui Guo
<firemeteor@users.sourceforge.net>
>> >>  Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
>> >>
>> >> Do I need to resend the whole thing out?
>> >
>> > I think it''s OK and Ian should be able to change those
lines for you
>> >
>> Thanks!
>> PS: I finally have i915 driver maintainer accepted my patch about the
>> pch detection.
>
> Nice. Which one was it? Do you have a URL for it?
>
This is the ack I got from the maintainer.
http://lists.freedesktop.org/archives/intel-gfx/2013-June/029171.html

Note that the i915 patch has to work together with this patch. It
won''t work by itself.
> Thanks!
>> So together with this patch, it would produce a working ouf-of-box
linux set.
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > http://lists.xen.org/xen-devel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On Tue, Jun 25, 2013 at 09:14:25PM +0800, G.R. wrote:
> On Sat, Jun 22, 2013 at 2:01 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Fri, Jun 21, 2013 at 09:25:49AM +0800, G.R. wrote:
> >> On Thu, Jun 20, 2013 at 9:31 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Mon, 17 Jun 2013, G.R. wrote:
> >> >> On Mon, Jun 17, 2013 at 8:54 PM, Jan Beulich
<JBeulich@suse.com> wrote:
> >> >> >>>> On 17.06.13 at 14:42, "G.R."
<firemeteor@users.sourceforge.net> wrote:
> >> >> >> The i915 driver probes chip version through PCH
ISA bridge device / vendor
> >> >> >> ID.
> >> >> >> Previously, the PCH ISA bridge is exposed as
PCI-PCI bridge in qemu-xen-trad,
> >> >> >> which breaks the assumption of the driver. This
change fixes the issue by
> >> >> >> correctly exposing the ISA bridge to domU.
> >> >> >>
> >> >> >> Note the PIIX3 ISA bridge is still present on
the bus (dropping it seems
> >> >> >> break qemu all-together), i915 driver still need
to be updated to handle
> >> >> >> this.
> >> >> >>
> >> >> >> Change since last version:
> >> >> >>   1. Introduce helper function to avoid exposing
PCI_Bus / PCI_Bridge
> >> >> >> definition to public.
> >> >> >>
> >> >> >> Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>,
> >> >> >>                Rui Guo
<firemeteor@users.sourceforge.net>
> >> >> >> Tested-by: Rui Guo
<firemeteor@users.sourceforge.net>
> >> >> >
> >> >> > I''m fine with this version, but does the
above indeed reflect
> >> >> > reality? I.e. wasn''t it you who wrote the
patch in its current
> >> >> > form?
> >> >> >
> >> >>
> >> >> Ah! Thanks for pointing this out...
> >> >> I just keep carrying this sign-off lines from the
original version.
> >> >> So I think I should use these lines for signing-off:
> >> >>  Signed-off-by: Rui Guo
<firemeteor@users.sourceforge.net>
> >> >>  Tested-by: Rui Guo
<firemeteor@users.sourceforge.net>
> >> >>
> >> >> Do I need to resend the whole thing out?
> >> >
> >> > I think it''s OK and Ian should be able to change
those lines for you
> >> >
> >> Thanks!
> >> PS: I finally have i915 driver maintainer accepted my patch about
the
> >> pch detection.
> >
> > Nice. Which one was it? Do you have a URL for it?
> >
> This is the ack I got from the maintainer.
> http://lists.freedesktop.org/archives/intel-gfx/2013-June/029171.html
> 
> Note that the i915 patch has to work together with this patch. It
> won''t work by itself.
Excellent. Good job!

Hello,

IanJ: I think this patch should be able to go in now that Xen 4.3 is out of the
way?


On Thu, Jun 20, 2013 at 02:31:44PM +0100, Stefano Stabellini
wrote:
> On Mon, 17 Jun 2013, G.R. wrote:
> > On Mon, Jun 17, 2013 at 8:54 PM, Jan Beulich <JBeulich@suse.com>
wrote:
> > >>>> On 17.06.13 at 14:42, "G.R."
<firemeteor@users.sourceforge.net> wrote:
> > >> The i915 driver probes chip version through PCH ISA bridge
device / vendor
> > >> ID.
> > >> Previously, the PCH ISA bridge is exposed as PCI-PCI bridge
in qemu-xen-trad,
> > >> which breaks the assumption of the driver. This change fixes
the issue by
> > >> correctly exposing the ISA bridge to domU.
> > >>
> > >> Note the PIIX3 ISA bridge is still present on the bus
(dropping it seems
> > >> break qemu all-together), i915 driver still need to be
updated to handle
> > >> this.
> > >>
> > >> Change since last version:
> > >>   1. Introduce helper function to avoid exposing PCI_Bus /
PCI_Bridge
> > >> definition to public.
> > >>
> > >> Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>,
> > >>                Rui Guo
<firemeteor@users.sourceforge.net>
> > >> Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
> > >
> > > I''m fine with this version, but does the above indeed
reflect
> > > reality? I.e. wasn''t it you who wrote the patch in its
current
> > > form?
> > >
> > 
> > Ah! Thanks for pointing this out...
> > I just keep carrying this sign-off lines from the original version.
> > So I think I should use these lines for signing-off:
> >  Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net>
> >  Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
> > 
> > Do I need to resend the whole thing out?
> 
> I think it''s OK and Ian should be able to change those lines for
you
>

-- Pasi

Pasi Kärkkäinen writes ("Re: [PATCH 2/3] V4 qemu-xen-trad: Correctly expose
PCH ISA bridge for IGD passthrough"):
> IanJ: I think this patch should be able to go in now that Xen 4.3 is out of
the way?
AFAICT from my mail archives the reason this patch was reverted, and
not reapplied, is that there are outstanding NAKs from Jan Beulich.

Last time you pinged about it we had a big discussion about how one
should figure out the status of the patch before pinging about it.
If the status is "awaiting patch submitter to revise following
comments" then the right thing to do is surely to ping the submitter.

If I''m wrong about the status of this patch then I''d welcome a
resend,
CC me, with Jan''s ack on it.

Ian.

On Wed, Jul 17, 2013 at 12:09:26PM +0100, Ian Jackson
wrote:
> Pasi Kärkkäinen writes ("Re: [PATCH 2/3] V4 qemu-xen-trad: Correctly
expose PCH ISA bridge for IGD passthrough"):
> > IanJ: I think this patch should be able to go in now that Xen 4.3 is
out of the way?
> 
> AFAICT from my mail archives the reason this patch was reverted, and
> not reapplied, is that there are outstanding NAKs from Jan Beulich.
> 
> Last time you pinged about it we had a big discussion about how one
> should figure out the status of the patch before pinging about it.
> If the status is "awaiting patch submitter to revise following
> comments" then the right thing to do is surely to ping the submitter.
> 
> If I''m wrong about the status of this patch then I''d
welcome a resend,
> CC me, with Jan''s ack on it.
>
Jan already Acked this patch, and Stefano also was OK with it.

G.R.: Can you please re-send it with the correct ack''s etc? 

-- Pasi

Pasi Kärkkäinen writes ("Re: [PATCH 2/3] V4 qemu-xen-trad: Correctly expose
PCH ISA bridge for IGD passthrough"):
> > If I''m wrong about the status of this patch then I''d
welcome a resend,
> > CC me, with Jan''s ack on it.
> 
> Jan already Acked this patch, and Stefano also was OK with it.
Oh, good.  I''m sorry I wasn''t able to find those mails.
> G.R.: Can you please re-send it with the correct ack''s etc? 
Yes, please.

Ian.