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

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Mon, Jul 15, 2013 at 01:47:43PM -0400, Ross Philipson wrote:
> On 07/15/2013 12:06 PM, Pasi Kärkkäinen wrote:
> >On Mon, Jul 01, 2013 at 09:06:37AM -0400, Konrad Rzeszutek Wilk wrote:
> >>>>>>>Or just scan through the capabilities, and chain only the ones
> >>>>>>>that we want to "Whitelist" and the rest are to be blacklisted.
> >>>>>>>The rest can also have its values set to some bogus value (0xdeadbeef?)
> >>>>>>>Perhaps only when built with 'debug=y'.
> >>>>>>
> >>>>>>
> >>>>>>That sounds about right. Back when I first did the patch (in an old 
> >>>>>>qemu)
> >>>>>>there were no other capabilities on the piix4 host bridge so it was 
> >>>>>>simple.
> >>>>>>Not sure if other capabilities will be an issue now.
> >>>>>
> >>>>>It's still the case as for the IVB host bridge.
> >>>>>And from what I can find from the datasheet for the Haswell, it's
> >>>>>still the case.
> >>>>>
> >>>>>Note that the datasheet explicitly documents the offset of the
> >>>>>CAPABILITY registers.
> >>>>>I guess there will be code that rely on this offset that been publicly
> >>>>>documented.
> >>>>>
> >>>>>Btw. Ross, now that you appears to be the original author (sorry for
> >>>>>mess you up with Jean),
> >>>>>could you also comment on my rework proposal? Jan believe the current
> >>>>>form is not clean enough.
> >>>>>
> >>>>>Currently we use a whitelist of registers to pass-through.How do you
> >>>>>come up with the current list?
> >>>>>The shadow copy way appears to work for the current list.
> >>>>
> >>>>OK.
> >>>>>But what if we are going to need some special registers that cannot be
> >>>>>handled well? (e.g. has side effect for reading and cannot perform
> >>>>>read-back?)
> >>>>
> >>>>Hopefully the i915 driver in Linux will help in figuring out which
> >>>>ones of those are needed?
> >>>I remember the vendor cap fix only helps windows guest.
> >>
> >>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..

-- Pasi


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