Re: [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci cap on host bridge.

["Pasi Kärkkäinen" <pasik@iki.fi>]

Hello Tiejun,

Since you've been working on upstreaming the Xen IGD passthru patches to qemu-upstream,
you might be able to comment on this patch aswell.

This patch is for qemu-traditional, but this one hasn't been acked / applied yet. 
It has been floating around on xen-devel for a couple of years now.
It would be nice to get this finally merged to qemu-traditional.. 

Can you comment about best approach to implement this patch?
There was some comments/concerns about the earlier versions.

"[PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci cap on host bridge.":
http://lists.xenproject.org/archives/html/xen-devel/2013-02/msg00538.html

And some discussion about the patch/justification one year ago:
http://lists.xen.org/archives/html/xen-devel/2013-07/msg01376.html


Also G.R. wrote earlier on this thread:

> I proposed an alternative to shadow the registers into the PCI config
> space of the emulated host controller.
> There seems no objection on this proposal. I'll do it when I got some spare time.


Thanks,

-- Pasi


On Tue, Aug 06, 2013 at 11:44:52AM +0800, G.R. wrote:
> On Tue, Aug 6, 2013 at 12:15 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Tue, Jul 16, 2013 at 01:55:20AM +0300, Pasi Kärkkäinen wrote:
> >> > >>How was that diagnosed? Perhaps that information can be part of the source
> >> > >>code to help in the future with diagnosiing which caps are needed and
> >> > >>which ones can be blacklisted?
> >> > >>
> >> > >
> >> > >I guess that's a question mostly for Ross/Jean as they're the original authors of the patch?
> >> >
> >> > We discovered the issue with Windows guests running the vendor
> >> > drivers for the passed in IGD graphics device. Under certain
> >> > circumstances (resuming from S3/S4 IIRC), the guest would BSOD. I
> >> > finally tracked it down to a bad state in the resuming driver
> >> > because it was not coded to handle the vendor capabilities not being
> >> > present on the host bridge. BTW, those capabilities are flags
> >> > indicating what features the IGD card has - their exact meaning is
> >> > of course proprietary.
> >> >
> >> > I cannot say it was only a problem on Windows but rather that that
> >> > is the only place we ever saw it.
> >> >
> >> > I never saw any other capabilities on the hosts bridges at that
> >> > time, just vendor ones so the patch just handled that. If there were
> >> > other capabilities, I would think it would have to be determined on
> >> > a case by case basis whether they were included. Inclusion of each
> >> > new type would have different ramifications it seems.
> >> >
> >>
> >> Thanks for the explanation. I guess parts of that should go to the patch description aswell..
> >>
> >
> > Now patch 2/3 has been applied to qemu-traditional, so only this patch 3/3 is missing from qemu-traditional from this series.
> >
> > Any other changes outstanding? or only to add some of Ross's comments to the patch description (and/or sources) ?
> >
> I'll have to rework this patch -- Jan believe the code is not very
> clean with regard to offset / size handling.
> 
> I proposed an alternative to shadow the registers into the PCI config
> space of the emulated host controller.
> There seems no objection on this proposal. I'll do it when I got some
> spare time.
> 
> > Thanks,
> >
> > -- Pasi
> >