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

["G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx>]

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

Thanks,
Timothy

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.

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