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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> >> >> 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?

> Linux guest just run happily without this.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
> 

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