[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Need help to debug win7 BSOD on IGD passthrough

On Tue, 15 Jan 2013, G.R. wrote:
> >> Also, I find that the patch does not work for the linux lspci.
> >> It seems to lack of the Caps bit in the status (0x6) register.
> >> But according to Ross, that bit only exists in spec 2.1 and becomes
> >> reserved in later specs.
> >> What do you think? Do we need to provide that bit also?
> >
> > Being Linux open, you can just clone the code of lspci and see what
> > exactly it is looking for.
> Well, I understand that Linux is open. But that's not my question.
> Ross's comment gave me the impression that lspci did not adhere to the 
> standard.
> So my question was actually to follow standard or lspci?
> After double checking the spec, it seems that Ross was talking about a
> different bit.
> The bit that once defined but now reserved is the UDF bit (bit 0x6) in
> the Status (ofs 0x6) reg.
> While I was talking about the Cap-list (bit 0x4) in the Status (ofs 0x6) reg.
> So it seems that the patch should be fixed to expose this bit and I
> need your suggestion here.
> Currently I have a quick and dirty hack locally to directly expose
> both command (word 0x4) && status (word 0x6) reg.
> I'm not sure if it's acceptable (probably not).
> I tend to provide read-only access since I have no idea what will
> happen if the guest ever try to operate on it (the host bridge
> 00:00.0)
> I'm not sure if I should expose the Status reg only and exclude
> Command reg (in case the Status reg is fully read-only, which I'm not
> sure about since I don't have the spec), or just fake a result for
> that register. If we choose to fake one, what should the result look
> like?

I would expose only the Status register, read-only.

> PS: it looks that the switch-on-address style of code is not very robust.
> This would fail if the guest access using unexpected alignment && length.
> I guess may be we should switch to a mask based implementation.

Given the way QEMU emulates the PCI config space, I don't think is
possible to receive a reads or writes with a length different from 1, 2 or
4 bytes.
However I am always open to code improvements.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.